4 ms·

One of the things I love about JavaScript is that you can write an almost 10x faster hash table than the standard library if you take care of cache misses and G

One of the things I love about JavaScript is that you can write an almost 10x faster hash table than the standard library if you take care of cache misses and GC: https://github.com/ronomon/hash-table#motivation https://github.com/ronomon/hash-table#motivation In fact, all the usual low-level optimization techniques like reducing branch mispredictions and expensive memory accesses apply, and make a huge difference, even though you're writing in a high-level language.

zamalek 6y ago
It's why managed languages have such a bad rap: people think that this stuff ceases to matter. I remember the C# DirectX billboard sample, it was something like 10x slower than the same C++ sample in the same version of the SDK. Why? C# didn't have generics yet, and a value type was being stored in a non-generic list. Something like 4MB of memory was being copied around due to boxing and unboxing. These things always matter.
_bxg1 6y ago
*for a very specific use-case where you have an ungodly amount of data to insert Still, it's interesting that there is something to be gained under these circumstances. I'm typically skeptical of this sort of thing because the standard library is written in C++. One time I thought I was very clever and hand-wrote a more appropriate sorting algorithm for a specific use-case only to discover that, no, Array.sort() was still faster by sheer brute force.
- austincheney 6y ago
  The algorithm for Array.sort is implementation specific, but there is an ECMAScript proposal for a standard algorithm.
- jorangreef 6y ago
  We actually wrote the original version in C with SIMD extensions as a Node.js binding, but the JavaScript version was still twice as fast. I kid you not. You will find the reason for this in the README, it's the last bullet point under "Fast": https://github.com/ronomon/hash-table#fast https://github.com/ronomon/hash-table#fast
  - _bxg1 6y ago
    Huh. Does that apply to WASM too or just to binding from Node?
    - jorangreef 6y ago
      I am not sure but I wouldn't think so, unless you have to serialize/deserialize or otherwise transform or inspect function call arguments in some or other way, as you need to do when binding JavaScript with C.
game_the0ry 6y ago
I do appreciate the effort the author put into that library and obviously performance is important. However, JS doesn't primarily live in the server side world, it mostly lives in the browser world. And in the browsers, you rarely do heavy processing. If you are, you're doing it wrong - that logic needs to live on the server. You're also doing it wrong in you are relying on server side NodeJS for tasks that involve heavy duty computations. Still, interesting to know. I wonder if the author can make this repo a proposal to the TC39 committee.
- ralphc 6y ago
  One of the selling points of tensorflow.js is that you do your processing on the client, for privacy reasons. This is heavy, heavy processing, and you're doing it right.
- _bxg1 6y ago
  > And in the browsers, you rarely do heavy processing. If you are, you're doing it wrong - that logic needs to live on the server. This is very incorrect. At my last company we had a React interface (a specialized IDE, really) that needed to juggle (sort, filter, process) and work with sometimes hundreds of thousands of entities at once, all in-memory. JavaScript did this just fine, and the user experience (and the API design) really benefitted from not having a bunch of extra round-trips to the server. Even in this extreme use-case, the bottleneck was always the few-hundred items that were actually rendered in the DOM at a time. We virtually never had performance problems from sheer volume of underlying data.
  - game_the0ry 6y ago
    > At my last company we had a React interface (a specialized IDE, really) that needed to juggle (sort, filter, process) and work with sometimes hundreds of thousands of entities at once, all in-memory. The author's example inserts 4M elements. > and the user experience (and the API design) really benefitted from not having a bunch of extra round-trips to the server. Possibly, but unless you benchmarked both scenarios, this might not be the case. Performance over networked devices often has trade offs, sometimes those trade offs are directly contradictory, eg sorting/filtering/mapping/etc data on client side versus server side via api call - sometimes one is better than the other but you wont wont know unless you benchmark. I get the impression that your company did not go through that exercise, considering you guys are building an IDE with scripting language.[1] [1] https://nickjanetakis.com/blog/switching-to-vscode-from-sublime-text#:~:text=Performance,an%20i5%203.2GHz%20CPU.&text=CTRL%2BP%20searching%20is%20slightly,or%20getting%20in%20the%20way https://nickjanetakis.com/blog/switching-to-vscode-from-subl....

zamalek 6y ago

It's why managed languages have such a bad rap: people think that this stuff ceases to matter. I remember the C# DirectX billboard sample, it was something like 10x slower than the same C++ sample in the same version of the SDK. Why? C# didn't have generics yet, and a value type was being stored in a non-generic list. Something like 4MB of memory was being copied around due to boxing and unboxing. These things always matter.

_bxg1 6y ago

*for a very specific use-case where you have an ungodly amount of data to insert Still, it's interesting that there is something to be gained under these circumstances. I'm typically skeptical of this sort of thing because the standard library is written in C++. One time I thought I was very clever and hand-wrote a more appropriate sorting algorithm for a specific use-case only to discover that, no, Array.sort() was still faster by sheer brute force.

austincheney 6y ago
The algorithm for Array.sort is implementation specific, but there is an ECMAScript proposal for a standard algorithm.
jorangreef 6y ago
We actually wrote the original version in C with SIMD extensions as a Node.js binding, but the JavaScript version was still twice as fast. I kid you not. You will find the reason for this in the README, it's the last bullet point under "Fast": https://github.com/ronomon/hash-table#fast https://github.com/ronomon/hash-table#fast
- _bxg1 6y ago
  Huh. Does that apply to WASM too or just to binding from Node?
  - jorangreef 6y ago
    I am not sure but I wouldn't think so, unless you have to serialize/deserialize or otherwise transform or inspect function call arguments in some or other way, as you need to do when binding JavaScript with C.

game_the0ry 6y ago

I do appreciate the effort the author put into that library and obviously performance is important. However, JS doesn't primarily live in the server side world, it mostly lives in the browser world. And in the browsers, you rarely do heavy processing. If you are, you're doing it wrong - that logic needs to live on the server. You're also doing it wrong in you are relying on server side NodeJS for tasks that involve heavy duty computations. Still, interesting to know. I wonder if the author can make this repo a proposal to the TC39 committee.

ralphc 6y ago
One of the selling points of tensorflow.js is that you do your processing on the client, for privacy reasons. This is heavy, heavy processing, and you're doing it right.
_bxg1 6y ago
> And in the browsers, you rarely do heavy processing. If you are, you're doing it wrong - that logic needs to live on the server. This is very incorrect. At my last company we had a React interface (a specialized IDE, really) that needed to juggle (sort, filter, process) and work with sometimes hundreds of thousands of entities at once, all in-memory. JavaScript did this just fine, and the user experience (and the API design) really benefitted from not having a bunch of extra round-trips to the server. Even in this extreme use-case, the bottleneck was always the few-hundred items that were actually rendered in the DOM at a time. We virtually never had performance problems from sheer volume of underlying data.
- game_the0ry 6y ago
  > At my last company we had a React interface (a specialized IDE, really) that needed to juggle (sort, filter, process) and work with sometimes hundreds of thousands of entities at once, all in-memory. The author's example inserts 4M elements. > and the user experience (and the API design) really benefitted from not having a bunch of extra round-trips to the server. Possibly, but unless you benchmarked both scenarios, this might not be the case. Performance over networked devices often has trade offs, sometimes those trade offs are directly contradictory, eg sorting/filtering/mapping/etc data on client side versus server side via api call - sometimes one is better than the other but you wont wont know unless you benchmark. I get the impression that your company did not go through that exercise, considering you guys are building an IDE with scripting language.[1] [1] https://nickjanetakis.com/blog/switching-to-vscode-from-sublime-text#:~:text=Performance,an%20i5%203.2GHz%20CPU.&text=CTRL%2BP%20searching%20is%20slightly,or%20getting%20in%20the%20way https://nickjanetakis.com/blog/switching-to-vscode-from-subl....