5 ms·

Better performance? What are you basing that on?

CmonDev 13y ago
VM-level support of generics, value types and tail call optimization. My knowledge could be outdated though. http://stackoverflow.com/a/267496/486561 http://stackoverflow.com/a/267496/486561 http://stackoverflow.com/a/480362/486561 http://stackoverflow.com/a/480362/486561
- trailfox 13y ago
  Scala implement tail call optimization in the compiler. In general the JVM has always outperformed the CLR: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=csharp&lang2=java&data=u64q http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
  - deleted 13y ago
    [deleted]
  - CmonDev 13y ago
    That's Mono - it lags behind .NET CLR.
    - trailfox 13y ago
      I know, but the .NET CLR has lagged the JVM for years in terms of performance, but its a few years since I did a comparison...
    - dragonwriter 13y ago
      > That's Mono - it lags behind .NET CLR. .NET is Windows-only, which is a significant limitation compared to the JVM. I don't think better performance on Windows -- even assuming going to CLR instead of JVM would provide that -- is a good reason for Scala to move to the CLR as the primary target.
      - CmonDev 13y ago
        I understand your point. Consider this: using Xamarin you can get native performance on iOS and better-than-Dalvik performance on Android. Is there a good tool chain for that in JVM/LLVM world that supports Scala?
        dragonwriter 13y ago
        "Better than Dalvik" isn't necessarily a compelling selling point looking forward, since Android is almost certainly going to moving from Dalvik to ART as the default runtime fairly soon.
  - kvb 13y ago
    Note that Scala doesn't implement general tail call optimization; it only applies to direct self-recursive calls (as far as I'm aware). By contrast, on .NET F# implements true tail call optimization, including cases where the call is statically unknown at compile time (as in `let apply f x = f x`).
- sluukkonen 13y ago
  Reified generics is one of the reasons why Scala on the .NET is effectively dead. The VM's type system isn't powerful enough to support some features of Scala, such as higher-kinded types.
  - CmonDev 13y ago
    JVM doesn't support reified generics for legacy reasons, it's said when need for compatibility slows down progress :(.
    - sluukkonen 13y ago
      But the JVM not having reified generics is a mostly a blessing for Scala. With reified generics, your language's type system can essentially be only as powerful as the VM's type system, and I think it's clear that Scala today wouldn't be the same if Sun had gone the reified generics route. (Still, it would be nice to have specialized generic containers for some primitive types in the JVM)
- MichaelGG 13y ago
  Tail calls are actually rather un-optimized in .NET. F# avoids them as much as possible. F# used to emit tail calls any time it could, but it hurt performance. IIRC, tail calls were also ignored in many areas prior to v4 (and they still have some limitations IIRC). The JVM could implement tailcalls via analysis; the tail prefix isn't truly needed. But Xamarin's porting of Java to C# to run Android on Mono without the JVM did show a rather large perf increase. I'd assume that's mostly generics eliminating boxing.
  - kvb 13y ago
    What do you mean by "The JVM could implement tailcalls via analysis"? Offhand, I can't see a way for this to be practically viable, but I may just be lacking imagination.
    - MichaelGG 13y ago
      Maybe I'm dense, but why not the same way a compiler implements it? In a recursive function, at the point of recursion, flag the call to have codegen not setup a new stackframe and just reuse the current frame. But you may be right that this might not be viable to run fast enough for JIT on a large codebase. Obviously you could tail-call enable every call that's eligible, but that probably doesn't generate optimal code. OTOH, they have tracing in the JIT for hotspot stuff, right? So if the tracing part counted how many call loops it had hit, it could decide to implement tailcalls in that path. Or perhaps it invokes analysis when the stack gets to be 75% full.
      - kvb 13y ago
        Right, my thought was that doing real tail calls everywhere that's eligible would almost certainly be a performance disaster. I'm not sure that hotspot could help, at least if applied naively, since correctness depends on never missing a tail call that could lead to unbounded stack usage. For example, consider an F#-like language on the JVM. Given the definition `let apply f x = f x`, you could imagine `apply` getting called in all sorts of contexts that don't result in unbounded recursion, so a hotspot-like system would not generate a tail call when compiling the method given the first N invocations. But then if another function is defined as `let rec loop n = if n < 1 then n else apply loop (n-1)` and invoked as `loop 10000000`, then the lack of a tail call in `apply` is fatal.

VM-level support of generics, value types and tail call optimization. My knowledge could be outdated though. http://stackoverflow.com/a/267496/486561 http://stackoverflow.com/a/267496/486561 http://stackoverflow.com/a/480362/486561 http://stackoverflow.com/a/480362/486561

trailfox 13y ago
Scala implement tail call optimization in the compiler. In general the JVM has always outperformed the CLR: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=csharp&lang2=java&data=u64q http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
- deleted 13y ago
  [deleted]
- CmonDev 13y ago
  That's Mono - it lags behind .NET CLR.
  - trailfox 13y ago
    I know, but the .NET CLR has lagged the JVM for years in terms of performance, but its a few years since I did a comparison...
  - dragonwriter 13y ago
    > That's Mono - it lags behind .NET CLR. .NET is Windows-only, which is a significant limitation compared to the JVM. I don't think better performance on Windows -- even assuming going to CLR instead of JVM would provide that -- is a good reason for Scala to move to the CLR as the primary target.
    - CmonDev 13y ago
      I understand your point. Consider this: using Xamarin you can get native performance on iOS and better-than-Dalvik performance on Android. Is there a good tool chain for that in JVM/LLVM world that supports Scala?
      - dragonwriter 13y ago
        "Better than Dalvik" isn't necessarily a compelling selling point looking forward, since Android is almost certainly going to moving from Dalvik to ART as the default runtime fairly soon.
- kvb 13y ago
  Note that Scala doesn't implement general tail call optimization; it only applies to direct self-recursive calls (as far as I'm aware). By contrast, on .NET F# implements true tail call optimization, including cases where the call is statically unknown at compile time (as in `let apply f x = f x`).
sluukkonen 13y ago
Reified generics is one of the reasons why Scala on the .NET is effectively dead. The VM's type system isn't powerful enough to support some features of Scala, such as higher-kinded types.
- CmonDev 13y ago
  JVM doesn't support reified generics for legacy reasons, it's said when need for compatibility slows down progress :(.
  - sluukkonen 13y ago
    But the JVM not having reified generics is a mostly a blessing for Scala. With reified generics, your language's type system can essentially be only as powerful as the VM's type system, and I think it's clear that Scala today wouldn't be the same if Sun had gone the reified generics route. (Still, it would be nice to have specialized generic containers for some primitive types in the JVM)
MichaelGG 13y ago
Tail calls are actually rather un-optimized in .NET. F# avoids them as much as possible. F# used to emit tail calls any time it could, but it hurt performance. IIRC, tail calls were also ignored in many areas prior to v4 (and they still have some limitations IIRC). The JVM could implement tailcalls via analysis; the tail prefix isn't truly needed. But Xamarin's porting of Java to C# to run Android on Mono without the JVM did show a rather large perf increase. I'd assume that's mostly generics eliminating boxing.
- kvb 13y ago
  What do you mean by "The JVM could implement tailcalls via analysis"? Offhand, I can't see a way for this to be practically viable, but I may just be lacking imagination.
  - MichaelGG 13y ago
    Maybe I'm dense, but why not the same way a compiler implements it? In a recursive function, at the point of recursion, flag the call to have codegen not setup a new stackframe and just reuse the current frame. But you may be right that this might not be viable to run fast enough for JIT on a large codebase. Obviously you could tail-call enable every call that's eligible, but that probably doesn't generate optimal code. OTOH, they have tracing in the JIT for hotspot stuff, right? So if the tracing part counted how many call loops it had hit, it could decide to implement tailcalls in that path. Or perhaps it invokes analysis when the stack gets to be 75% full.
    - kvb 13y ago
      Right, my thought was that doing real tail calls everywhere that's eligible would almost certainly be a performance disaster. I'm not sure that hotspot could help, at least if applied naively, since correctness depends on never missing a tail call that could lead to unbounded stack usage. For example, consider an F#-like language on the JVM. Given the definition `let apply f x = f x`, you could imagine `apply` getting called in all sorts of contexts that don't result in unbounded recursion, so a hotspot-like system would not generate a tail call when compiling the method given the first N invocations. But then if another function is defined as `let rec loop n = if n < 1 then n else apply loop (n-1)` and invoked as `loop 10000000`, then the lack of a tail call in `apply` is fatal.