A young computer scientist and two colleagues show that searches within data structures called hash tables can be much faster than previously deemed possible.
-
anything that deserializes arbitrary json will put it into a hash table, right? it would definitely speed up the web.
-
Very sus. This article is not technically counvincing at all. Probably a few students who dream of inventing the next big thing. Hash tables complexity was mathematically proven to be generally optimal. If you think you optimized it it's because your tests don't reflect the common real world
-
I also trust the legitimacy of the discovery. There's a lot of fake 'discovery' articles out there.
-
Hash tables are often used behind the scenes. dicts and sets in python both utilize hash tables internally, for example.
-
I haven't read the Tiny Pointers article yet, but the OP article implies that the new hash tables may rely on them. If so, then the blocker could be the introduction (or lack thereof) of tiny pointers in programming languages.
-
Infrastructural APIs are much slower to change, and in a lot of cases the use of those APIs are dependent on a specific version. The change will definitely occur over time as the practical limitations are discovered
-
After reading through the abstract the article is pop sci bunk: They developed a method to save additional space with constant-time overhead.
Which is certainly novel and nice and all kinds of things but it's just a tool in the toolbox, making things more optimal in theory says little about things being faster in practice because the theoretical cost models never match what real-world machines are actually doing. In algorithm classes we learn to analyse sorting algorithms by number of comparisons, and indeed the minimum necessary is O(n log n), in the real world, it's numbers of cache invalidation that matters: CPUs can compare numbers basically instantly, getting the stuff you want to compare from memory to the CPU is where time is spent. It can very well be faster to make more comparisons if it means you get fewer, or more regular (so that the CPU can predict and pre-fetch), data transfers.
Consulting my crystal ball, I see this trickling down into at least the minds of people who develop the usual KV stores, database engineers, etc, maybe it'll help maybe it won't those things are already incredibly optimized. Never trust a data structure optimisation you didn't benchmark. Never trust any optimisation you didn't benchmark, actually. Do your benchmarks, you're not smarter than reality. In case it does help, it's going to trickle down into standard implementations of data structures languages ship with.
-
This is the paper the article is about: https://arxiv.org/pdf/2501.02305
-
Also never even start optimizing until you profile and are sure the bit you are trying to optimize even matters to the overall performance of your program.
-
Using bencode over json would probably speed up the web more. Not to mention good ole X.690. The web is completely cooked when it comes to efficiency.
-
The fact that you can achieve a constant average query time, regardless of the hash table’s fullness, was wholly unexpected — even to the authors themselves.
WTF?
I mean first of all, the "article" is just crap IMO, like only hinting att "anazing" things. But also containing basic errors like the above. It's like they don't understand complexity, a constant average time on what? A specific size of a hash table? Or do they mean it scales linearly with its size? Just go through the whole table and voila you have constant time already.
So if they did find something, it's not well explained in the article IMO. Shame, cause those kind of things are interesting, IMO.
-
the biggest speedup would probably come from using proper schemas that can be efficiently parsed. but we've made our bed out of ad-hoc protocols.
-
"Constant average query time" is not that hard to understand. It means that sometimes access time is e.g. linear, and sometimes you get your content before executing the code. With a hash table large enough and full enough, this can be used to fetch content seconds, minutes, days, potentially years before the program even exists. That's one hell of a breakthrough.
-
I've only used java but java hash tables are stupid fast in my experience, like everything else in my crap programs was 1000 times slower than the hash table access or storage.
-
The paper was published by IEEE and with professors as co-authors. Only the second author is a student. And I wouldn't dismiss it out of hand like that because of a magazine article. Students come up with breakthroughs all the time.
The paper itself says it disproves Yao's conjecture. I personally plan to implement and benchmark this because the results seem so good. It could be another fibonacci heap situation, but maybe not. Hash tables are so widely used, that it might even be worthwhile to make special hardware to use this on servers, if our current computer architecture is only thing that holds back the performance.Edit: author sequence
-
And yet all that pales in comparison to using react (or whatever framework) over vanilla js. Enter McMaster-Carr.
-
yupyup, just send HTML over the wire. it's fine.
-
Hash trees are super efficient when they're not nearly full. So the standard trick is just to resize them when they're too close to capacity.
The new approach is probably only going to be useful in highly memory constrained applications, where resizing isn't an option.
-
Depends on the implementation, but most will, yes. There are other forms of associative arrays, like trie or binary tree, but hash is the most common.
-
JSON libraries are stupidly well optimized. There are binary encoding schemes that are faster and more compact, but its hard to beat JSON for text-based.
