7 ms·

But that's why Swift generates slower code. Memory is cheap, also for Apple, although Apple would like to hide that fact.

by pebal 1y ago

sedatk 1y ago
Have you seen the benchmarks? Swift code is 40% faster than Java in that instance.
- pjmlp 1y ago
  I have indeed, https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages
  - tgffdd 1y ago
    No wonder Swift performs unwell in this benchmark. The Swift implementation is written very poorly, done by developers obviously unexperienced in writing proper Swift :)
- vips7L 1y ago
  I don’t think anyone actually believes that the language change is what made the difference in that post. As far as anyone can tell there were 2 things that made their rewrite better: 1. They had experience on the type of app and you tend to do things better when you do it the second time. 2. Reading between the lines they were likely running an ancient version of Java from 10+ years ago.
  - sedatk 1y ago
    > I don’t think anyone actually believes that the language change is what made the difference in that post They already admit in the article that JVM setup costs were a huge overhead during scaling operations. JIT might also incur a similar overhead at the same stage. So, not the language per se, but the runtime difference must have made a difference. Compiled native code may not be too different between the two. But, in terms of memory management, Swift's ability to keep the heap in a smaller area might contribute to better cache utilization which might implicitly contribute to performance. In the end, as you said, writing better code the second time might have made the greatest contribution of course. That doesn't necessarily mean that language change has made no difference.
    - vips7L 1y ago
      > They already admit in the article that JVM setup costs were a huge overhead during scaling operations. JIT might also incur a similar overhead at the same stage. Yeah the startup costs are an active problem. I do think though that if they weren’t running an old runtime they wouldn’t have had the same GC issues.

But that's why Swift generates slower code. Memory is cheap, also for Apple, although Apple would like to hide that fact.

by pebal 1y ago

But that's why Swift generates slower code. Memory is cheap, also for Apple, although Apple would like to hide that fact.

sedatk 1y ago

Have you seen the benchmarks? Swift code is 40% faster than Java in that instance.

pjmlp 1y ago
I have indeed, https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages
- tgffdd 1y ago
  No wonder Swift performs unwell in this benchmark. The Swift implementation is written very poorly, done by developers obviously unexperienced in writing proper Swift :)
vips7L 1y ago
I don’t think anyone actually believes that the language change is what made the difference in that post. As far as anyone can tell there were 2 things that made their rewrite better: 1. They had experience on the type of app and you tend to do things better when you do it the second time. 2. Reading between the lines they were likely running an ancient version of Java from 10+ years ago.
- sedatk 1y ago
  > I don’t think anyone actually believes that the language change is what made the difference in that post They already admit in the article that JVM setup costs were a huge overhead during scaling operations. JIT might also incur a similar overhead at the same stage. So, not the language per se, but the runtime difference must have made a difference. Compiled native code may not be too different between the two. But, in terms of memory management, Swift's ability to keep the heap in a smaller area might contribute to better cache utilization which might implicitly contribute to performance. In the end, as you said, writing better code the second time might have made the greatest contribution of course. That doesn't necessarily mean that language change has made no difference.
  - vips7L 1y ago
    > They already admit in the article that JVM setup costs were a huge overhead during scaling operations. JIT might also incur a similar overhead at the same stage. Yeah the startup costs are an active problem. I do think though that if they weren’t running an old runtime they wouldn’t have had the same GC issues.