I'm fond of this brain-expander, in spirit of TFA: "Did you know travelling salesperson is O(N) on a large class of graphs?"
Another insight: I regularly find that clever O(logn) solutions are just obliterated by a few mostly-branch-free O(N) pre-passes followed by a problem that computers enjoy, like contiguous memory access and vector operations.
Yeah why is "the algorithm" the thing we do in our head to mimick a 1970s computer and not what really happens on hardware.
At risk of disclosing certain personal details about myself on the internet, I pinky-promise that the two aren't as different as folks without certain cognitive limitations might think.
Use the royal "we" with caution, please.
P.S. in case it wasn't obvious, this isn't one of those "nyeh nyeh well you must be dumb because you don't cogitate in ways reminiscent of modern computing hardware" comments so much as a "you would not believe how simple-as-in-basic-as-in-limited some of us really cogitate while leveraging external systems to suggest otherwise ".
Why is it a limitation to know about SIMD, AVX, L1 cache etc.? Or am I missing your point?
Do you have any examples of the second class?
The one that comes to mind is how big your hash maps have to get before all the clever algorithms beat linear scan, and it's surprisingly large on modern computers: linear memory access is _very_ predictable.
The Roc and Zig folks probably have actual numbers.
What are these surprisingly large numbers you've seen? I thought that linear scan optimizations are typically reserved for pretty small maps, like dozens or maybe hundreds of elements.
Hundreds sounds about right, maybe up to a thousand.
But nobody expects that. Hashmap is supposed to be faster once you have, like, ten elements. That's what was promised to us.
Maybe more than that if you have a sub-optimal hash map implementations. There are a bunch of those floating around - for example, Java's build-in HashMap has traditionally been kneecapped by lack of value types, and if you are not careful you can incur 2x cache misses per lookup...
Same with c++ stl unordered_map
Yeah, I found hundreds surprising (although not on reflection).
Depends on comparison function. In clickhouse-c for type name lookup it's strcmp so I use generated hash table with no collisions & reusing cityhash function since we have it handy: https://github.com/ClickHouse/clickhouse-c/blob/4bdd89a02438...
Benchmarked an order of magnitude faster than linear scan or binary search. I agree with your general sentiment tho, which is why I measured
Not sure if this counts, but I learned Huffman coding the intuitive tree-based way. From memory it was O(nlogn), but you can just O(n) it in-place in an array.
Huffman decoding you mean. All the fast decoders build tables processing N (8, 16, ...) bits at a time. If the next byte is 253 in state 6 that means output 15,28,28 and go to state 42...
There are probably even faster ways I don't know of.
You can't do it faster than O(n log n) for the simple reason that you need to sort the frequencies. If the symbols come sorted, then you can do it in O(n) time, yes, using two queues.
[dead]