6 ms·

> JVM issues stop the world GC (my car ran you over because of a random unpredictable pause!) its bytecode is object-oriented impossible at the moment to do

by zelly 7y ago

> JVM issues stop the world GC (my car ran you over because of a random unpredictable pause!) its bytecode is object-oriented impossible at the moment to do CUDA style GPU programming without horrible JNI calls > F# on .net core can be distributed without installing a runtime nor does garbage collection limit its expressiveness F# has two big crippling factors: (1) the .NET at the end of its name and (2) functional programming, which is a huge barrier for 99% of developers (and it's not functional enough for the other 1%). F# is dead in the water--I mean that respectfully. To replace Python for deep learning, you need a language that other people will actually use, not should.

Cybiote 7y ago
> stop the world GC (my car ran you over because of a random unpredictable pause!) Given a certain baseline of available resources and for the places where GC issues can be problematic (regimes I do not believe common) unpredictability of GC is the main issue, which can be readily addressed. You can for example, allocate and then manually manage or opt for a specialized JVM. If startup-time is an issue there are native compilation options. Or just not use the JVM, that's an option too. I'll also note that Automatic reference counting is no panacea either and Python is no better suited for the scenario you've given. Personally, I've not found this to be an issue given modern low pause concurrent GC but your mileage may vary. > its bytecode is object-oriented > impossible at the moment to do CUDA style GPU programming without horrible JNI calls I don't think these are deal breakers. More easily writing kernels in a high level language is very much an open problem. Even Tensorflow faces this issue, with most workflows optimized for a handful of prewritten kernels. On the JVM there are options such as https://index.scala-lang.org/thoughtworksinc/compute.scala/benchmarks/0.4.3+122-322540ce?target=_2.12 https://index.scala-lang.org/thoughtworksinc/compute.scala/b... or http://aparapi.com/ http://aparapi.com/ for GPU backed ND-arrays or JVM translation. > F# has two big crippling factors: (1) the .NET at the end of its name and (2) functional programming, which is a huge barrier for 99% of developers (and it's not functional enough for the other 1%). F# is dead in the water--I mean that respectfully. To replace Python for deep learning, you need a language that other people will actually use, not should. I don't think (1) is true or even if so, see its technical relevance. If you're doing numeric/array-based differentiable programming then you shouldn't have any problem with functional programming. I'd even argue functional programming makes things easier as you get many things free from existing combinators. Many concepts are naturally expressed with the features such languages tend to have. I don't think Python needs replacement, I'd much more rather see interoperability and language agnosticism. I can tell you that for each of Julia, Haskell, Scala, Kotlin, Ocaml, Nim, F#, Rust and of course Swift, at least one fascinating machine learning library is being built. I think that's a great thing.
- Stubb 7y ago
  Can you expand on F# not being functional enough for the other 1%?
  - Cybiote 7y ago
    I do not believe this generalization is accurate. It wasn't me who said that but the person I quoted. F# is plenty functional but what it does lack are organizational constructs which reduce code duplication. In practice, these are not deal breakers for what you get in return (especially that you can work around them by leveraging more OOP features, which isn't necessarily a bad thing) but that as always, depends on preferences and priorities. Among functional languages, F# is pretty streamlined, believe it or not. F#'s pragmatism means the subset of Haskell that gets used in practice to keep things simple shares a fair amount of overlap with F#. Even more-so for Ocaml. But, the person might have meant something like, if you already know Ocaml, you might complain about the lack of functors or polymorphic variants. Similarly, if you already know Haskell you might complain about the lack of higher-kinded types or GADTs. On the other hand, F# offers its own features (clean implementations of active patterns, computation expressions, type providers, async, multicore) and advantages, mostly from being able to leverage the .NET ecosystem (which also explains why those specific features are missing).
fulafel 7y ago
Is Swift's GC real-time, then? I thought it's just normal refcounting with unbounded stop times.
- zapzupnz 7y ago
  Swift has no GC, just ARC (automatic refcounting).
  - pjmlp 7y ago
    Swift has a GC, what it doesn't have is a tracing GC.
    - jchb 7y ago
      Technically it is a form of garbage collection. However, garbage collection is a very broad term that arguably encompasses even C++ smart pointers. Typically one refers to a garbage collector in the meaning of a separate process that runs independent of the application. Either in the background or “stopping the world” to collect. ARC is part of the application code. It is also visible to the compilers optimizer, which can optimize away redundant redundant reference count operations.
      - fulafel 7y ago
        In your division, ARC is stop-the-world variety because things like cascading deallocations cause unbounded work.
      - pjmlp 7y ago
        Typically one refers to the CS definition of automatic memory management, using accredited references like "The Garbage Collection Handbook: The Art of Automatic Memory Management". Everything from "ARC" is there on chapter 5.
- zelly 7y ago
  No, but ARC does not have to pause all threads. Also this exists: https://developer.apple.com/documentation/swift/unsafemutablerawpointer/2949656-deallocate https://developer.apple.com/documentation/swift/unsafemutabl...
thom 7y ago
For what it's worth, Neanderthal in Clojure gives very smooth access to CUDA: https://neanderthal.uncomplicate.org/ https://neanderthal.uncomplicate.org/

by zelly 7y ago

Cybiote 7y ago

> stop the world GC (my car ran you over because of a random unpredictable pause!) Given a certain baseline of available resources and for the places where GC issues can be problematic (regimes I do not believe common) unpredictability of GC is the main issue, which can be readily addressed. You can for example, allocate and then manually manage or opt for a specialized JVM. If startup-time is an issue there are native compilation options. Or just not use the JVM, that's an option too. I'll also note that Automatic reference counting is no panacea either and Python is no better suited for the scenario you've given. Personally, I've not found this to be an issue given modern low pause concurrent GC but your mileage may vary. > its bytecode is object-oriented > impossible at the moment to do CUDA style GPU programming without horrible JNI calls I don't think these are deal breakers. More easily writing kernels in a high level language is very much an open problem. Even Tensorflow faces this issue, with most workflows optimized for a handful of prewritten kernels. On the JVM there are options such as https://index.scala-lang.org/thoughtworksinc/compute.scala/benchmarks/0.4.3+122-322540ce?target=_2.12 https://index.scala-lang.org/thoughtworksinc/compute.scala/b... or http://aparapi.com/ http://aparapi.com/ for GPU backed ND-arrays or JVM translation. > F# has two big crippling factors: (1) the .NET at the end of its name and (2) functional programming, which is a huge barrier for 99% of developers (and it's not functional enough for the other 1%). F# is dead in the water--I mean that respectfully. To replace Python for deep learning, you need a language that other people will actually use, not should. I don't think (1) is true or even if so, see its technical relevance. If you're doing numeric/array-based differentiable programming then you shouldn't have any problem with functional programming. I'd even argue functional programming makes things easier as you get many things free from existing combinators. Many concepts are naturally expressed with the features such languages tend to have. I don't think Python needs replacement, I'd much more rather see interoperability and language agnosticism. I can tell you that for each of Julia, Haskell, Scala, Kotlin, Ocaml, Nim, F#, Rust and of course Swift, at least one fascinating machine learning library is being built. I think that's a great thing.

Stubb 7y ago
Can you expand on F# not being functional enough for the other 1%?
- Cybiote 7y ago
  I do not believe this generalization is accurate. It wasn't me who said that but the person I quoted. F# is plenty functional but what it does lack are organizational constructs which reduce code duplication. In practice, these are not deal breakers for what you get in return (especially that you can work around them by leveraging more OOP features, which isn't necessarily a bad thing) but that as always, depends on preferences and priorities. Among functional languages, F# is pretty streamlined, believe it or not. F#'s pragmatism means the subset of Haskell that gets used in practice to keep things simple shares a fair amount of overlap with F#. Even more-so for Ocaml. But, the person might have meant something like, if you already know Ocaml, you might complain about the lack of functors or polymorphic variants. Similarly, if you already know Haskell you might complain about the lack of higher-kinded types or GADTs. On the other hand, F# offers its own features (clean implementations of active patterns, computation expressions, type providers, async, multicore) and advantages, mostly from being able to leverage the .NET ecosystem (which also explains why those specific features are missing).

fulafel 7y ago

Is Swift's GC real-time, then? I thought it's just normal refcounting with unbounded stop times.

zapzupnz 7y ago
Swift has no GC, just ARC (automatic refcounting).
- pjmlp 7y ago
  Swift has a GC, what it doesn't have is a tracing GC.
  - jchb 7y ago
    Technically it is a form of garbage collection. However, garbage collection is a very broad term that arguably encompasses even C++ smart pointers. Typically one refers to a garbage collector in the meaning of a separate process that runs independent of the application. Either in the background or “stopping the world” to collect. ARC is part of the application code. It is also visible to the compilers optimizer, which can optimize away redundant redundant reference count operations.
    - fulafel 7y ago
      In your division, ARC is stop-the-world variety because things like cascading deallocations cause unbounded work.
    - pjmlp 7y ago
      Typically one refers to the CS definition of automatic memory management, using accredited references like "The Garbage Collection Handbook: The Art of Automatic Memory Management". Everything from "ARC" is there on chapter 5.
zelly 7y ago
No, but ARC does not have to pause all threads. Also this exists: https://developer.apple.com/documentation/swift/unsafemutablerawpointer/2949656-deallocate https://developer.apple.com/documentation/swift/unsafemutabl...

thom 7y ago

For what it's worth, Neanderthal in Clojure gives very smooth access to CUDA: https://neanderthal.uncomplicate.org/ https://neanderthal.uncomplicate.org/