4 ms·

What's wrong with JS/TS or Lua as a fast dynamic language?

by __s 3y ago

jakobnissen 3y ago
Javascript doesn't compile to native code, so isn't as fast. I've never tried LuaJIT, though, that's supposed to be on par with Julia.
- ReleaseCandidat 3y ago
  > Javascript doesn't compile to native code, so isn't as fast. There are AOT compilers for JS.
  - jakobnissen 3y ago
    So there is for Python, but it's still slow. JS has slow semantics. It can't be made in the same performance league as Julia.
- yabbs 3y ago
  I think you mean Julia is on par with LuaJIT? ..maybe exceeds?
markkitti 3y ago
One of my favorite things recently is using JS/TS with Julia, usually via a Pluto.jl notebook. There are also some nice demonstrations showing Julia compiled to web assembly. https://tshort.github.io/WebAssemblyCompiler.jl/stable/examples/lorenz/?p1=9.6 https://tshort.github.io/WebAssemblyCompiler.jl/stable/examp...
tonyarkles 3y ago
I mean, JS, TS, and Python all have at least one major problem: threading. I don’t recall how Lua threads work but I have a feeling it too suffers.
- __s 3y ago
  There's threading in lua https://github.com/torch/threads https://github.com/torch/threads
  - tonyarkles 3y ago
    Ahhh, interesting. That looks to me like it's more appropriate for "multiple threads working on independent problems" than "multiple threads working on the same problem" due to the potential serialization overhead and limitations. Each thread has its own lua_State. However, we provide a serialization scheme which allows automatic sharing for several Torch objects (storages, tensors and tds types). Sharing of vanilla lua objects is not possible, but instances of classes that support serialization (eg. classic objects with using require 'classic.torch' or those created with torch.class) can be shared, but remember that only the memory in tensor storages and tds objects will be shared by the instances, other fields will be copies. Also if synchronization is required that must be implemented by the user (ie. with mutex). That's not general-purpose multi-processor threading, that's solving it for a very specific sub-problem.

What's wrong with JS/TS or Lua as a fast dynamic language?

by __s 3y ago

What's wrong with JS/TS or Lua as a fast dynamic language?

Javascript doesn't compile to native code, so isn't as fast. I've never tried LuaJIT, though, that's supposed to be on par with Julia.

ReleaseCandidat 3y ago
> Javascript doesn't compile to native code, so isn't as fast. There are AOT compilers for JS.
- jakobnissen 3y ago
  So there is for Python, but it's still slow. JS has slow semantics. It can't be made in the same performance league as Julia.
yabbs 3y ago
I think you mean Julia is on par with LuaJIT? ..maybe exceeds?

markkitti 3y ago

One of my favorite things recently is using JS/TS with Julia, usually via a Pluto.jl notebook. There are also some nice demonstrations showing Julia compiled to web assembly. https://tshort.github.io/WebAssemblyCompiler.jl/stable/examples/lorenz/?p1=9.6 https://tshort.github.io/WebAssemblyCompiler.jl/stable/examp...

tonyarkles 3y ago

I mean, JS, TS, and Python all have at least one major problem: threading. I don’t recall how Lua threads work but I have a feeling it too suffers.

__s 3y ago
There's threading in lua https://github.com/torch/threads https://github.com/torch/threads
- tonyarkles 3y ago
  Ahhh, interesting. That looks to me like it's more appropriate for "multiple threads working on independent problems" than "multiple threads working on the same problem" due to the potential serialization overhead and limitations. Each thread has its own lua_State. However, we provide a serialization scheme which allows automatic sharing for several Torch objects (storages, tensors and tds types). Sharing of vanilla lua objects is not possible, but instances of classes that support serialization (eg. classic objects with using require 'classic.torch' or those created with torch.class) can be shared, but remember that only the memory in tensor storages and tds objects will be shared by the instances, other fields will be copies. Also if synchronization is required that must be implemented by the user (ie. with mutex). That's not general-purpose multi-processor threading, that's solving it for a very specific sub-problem.