4 ms·
>JS with JIT is waaay faster than Python. Not “between python and java” as purported. You are correct that JS is not between Python and Java. Python is faster
by fnord123 7y ago
>JS with JIT is waaay faster than Python. Not “between python and java” as purported.
You are correct that JS is not between Python and Java. Python is faster than Java which is faster than JS. Though some people seem to think calling APIs written in C is "not Python" but if the ecosystem provides the library and I call it from Python then it's Python enough for me!
- gbear605 7y agoBy that logic, Python, Javascript, and Java are all the same speed, just call out to C, or assembly perhaps if you really want to tune some code.
- fnord123 7y agoNo, not at all. Java FFI is extremely expensive.
- pizlonator 7y agoYeah. And so is JS’s. I think CPython’s design makes it a champ at native interop and a loser at pure compute perf. That’s a valid trade off for lots of important situations.
- frankpf 7y agoAre you referring to V8's/Node's C FFI? Why is that extremely expensive?
- smabie 7y agoIt's not a trade-off. There's no reason why you can't have a blazing fast and expressive language that also has good C FFI. A single good programmer could make a language that was as expressive as Python (that is, not very), faster, and with a good C FFI in under 6 months.
- progval 7y agoAren't you saying it's possible to make a perfect language with no tradeoff, and all that in just 6 months?
- pizlonator 7y agoYou couldn’t be more wrong. Java and JS have expensive FFI because of the specific costs of synchronizing the VM entry/exit with the GC and JITs.
- smabie 7y agoWhat you're implying is that the "speed" of a language is purely defined by the speed of the C FFI? This view is absolutely ridiculous and I don't think you would find a single other programmer on this green earth that would agree with you.
- fnord123 7y agoI think everyone agrees that when they want to do some data analysis they pip install numpy and get to work. It's only the navel gazers who are concerned about cpythons performance instead of treating python as a 'race to C' wherever performance is concerned. Get used to this approach since it crops up everywhere. If you target a gpu, you try to keep the work in the gpu. When we move to use bpf and io_uring things will be a race to the next kernel program. If you target the CPU then your code is a race to C or a race to the function that calls the relevant cpu instruction that will make your code fly.