4 ms·

Non-trivial numerics are done through FFI in python. Python doesn’t support fp16, but a native library behind it does. The exact same premise applies to JavaS

Non-trivial numerics are done through FFI in python. Python doesn’t support fp16, but a native library behind it does. The exact same premise applies to JavaScript

yyyk 4y ago
If you're doing all the interesting bits via FFI, Javascript JIT does not give you much aside from a lot of extra work. Why should we reimplement the glue code for marginal improvements? If you are doing stuff without FFI, than JS's inadequacies do matter. IMHO, you can't beat Python for ML by being just a slightly faster Python (there aren't enough newcomers for that, the Python ecosystem is enough to assimilate them before other languages can). You need to offer something more significant to make migration worthwhile. Julia tries to do that by allowing to implement the main stack in Julia, if it had JS speed and DX it would have eaten Python's lunch.
- brrrrrm 4y ago
  err, how is JS inadequate for that stuff? Python does not have fp16 support natively, neither does JS. It also doesn't have fp32, int64, int8, int32, uint32 etc. JavaScript does? JavaScript is 43 times faster for this random workload: (env) bwasti@bwasti-mbp ~ % time python bleh.py python bleh.py 9.27s user 0.06s system 99% cpu 9.352 total (env) bwasti@bwasti-mbp ~ % time bun bleh.ts bun bleh.ts 0.16s user 0.02s system 83% cpu 0.216 total (env) bwasti@bwasti-mbp ~ % cat bleh.py import random v = [0 for i in range(1000000)] for i in range(int(1e8)): v[i % len(v)] += 1 (env) bwasti@bwasti-mbp ~ % cat bleh.ts const v = new Float32Array(1000000) for (let i = 0; i < 1e8; ++i) { v[i % v.length] += 1 } Try as many as you want and you'll see that it just blows python out of the water
  - yyyk 4y ago
    I understand that V8 JIT is way faster than raw python. The proper comparison is against python+FFI though. My point was that rewriting mere glue code is apparently not considered cost effective by the community.

Non-trivial numerics are done through FFI in python. Python doesn’t support fp16, but a native library behind it does. The exact same premise applies to JavaScript

yyyk 4y ago

If you're doing all the interesting bits via FFI, Javascript JIT does not give you much aside from a lot of extra work. Why should we reimplement the glue code for marginal improvements? If you are doing stuff without FFI, than JS's inadequacies do matter. IMHO, you can't beat Python for ML by being just a slightly faster Python (there aren't enough newcomers for that, the Python ecosystem is enough to assimilate them before other languages can). You need to offer something more significant to make migration worthwhile. Julia tries to do that by allowing to implement the main stack in Julia, if it had JS speed and DX it would have eaten Python's lunch.

brrrrrm 4y ago
err, how is JS inadequate for that stuff? Python does not have fp16 support natively, neither does JS. It also doesn't have fp32, int64, int8, int32, uint32 etc. JavaScript does? JavaScript is 43 times faster for this random workload: (env) bwasti@bwasti-mbp ~ % time python bleh.py python bleh.py 9.27s user 0.06s system 99% cpu 9.352 total (env) bwasti@bwasti-mbp ~ % time bun bleh.ts bun bleh.ts 0.16s user 0.02s system 83% cpu 0.216 total (env) bwasti@bwasti-mbp ~ % cat bleh.py import random v = [0 for i in range(1000000)] for i in range(int(1e8)): v[i % len(v)] += 1 (env) bwasti@bwasti-mbp ~ % cat bleh.ts const v = new Float32Array(1000000) for (let i = 0; i < 1e8; ++i) { v[i % v.length] += 1 } Try as many as you want and you'll see that it just blows python out of the water
- yyyk 4y ago
  I understand that V8 JIT is way faster than raw python. The proper comparison is against python+FFI though. My point was that rewriting mere glue code is apparently not considered cost effective by the community.