Re:Atom's new concurrency-friendly buffer implementation
by CharlesW on Thursday October 12, 2017 @08:21PM
(#15462449)
Could WebAssembly, at least when fully realized, be used for this kind of "custom data structure" optimization?
[ Parent
| on HN ]
Re:Atom's new concurrency-friendly buffer implementation
by maxbrunsfeld on Friday October 13, 2017 @11:35PM
(#15470567)
We are already able to run native code in Atom via node's native extensions, so we have no reason to wait for WebAssembly.
The only benefit of WebAssembly would be if we wanted to port Atom to work in a regular web browser. We can even already do that without WebAssembly by compiling the superstring library to JS with emscripten. This works today and benchmarks show that it's already quite fast, but I think WebAssembly will make it even more efficient.
Re:Atom's new concurrency-friendly buffer implementation
by CyberDildonics on Thursday October 12, 2017 @10:45PM
(#15462952)
Yes, but even faster would be actual native instructions run directly by your CPU.
Re:Atom's new concurrency-friendly buffer implementation
by bicubic on Thursday October 12, 2017 @11:30PM
(#15463081)
So... webassembly?
Re:Atom's new concurrency-friendly buffer implementation
by akmittal on Friday October 13, 2017 @12:47AM
(#15463337)
Webassembly run on VM for portability.
Re:Atom's new concurrency-friendly buffer implementation
by Frizi on Friday October 13, 2017 @03:18AM
(#15463769)
Which in turn JIT compiles the code down to your specific hardware, possibly doing some extra optimizations along the way as it cares only about a single processor at a time. I do think languages like Rust are really superior to what we have in JS land, but the VMs there are truly a marvel of modern engineering.
Re:Atom's new concurrency-friendly buffer implementation
by CyberDildonics on Friday October 13, 2017 @09:59AM
(#15465705)
Yikes, do you not realize that there is a difference between webassembly and actual native instructions?