5 ms·
Heres from a quick Google http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=swift http://benchmarksgame.alioth.debian.org/u64q/compare.php
by devsquid 11y ago
Heres from a quick Google
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=swift http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
You can see like most Swift benchmarks, its compiling with the -Ounchecked flag and using C.
-edit- I have no doubts of LLVM's capabilities. It just seems like Swift is probably already taking advantage of its optimizations.
- pcwalton 11y ago> It just seems like Swift is probably already taking advantage of its optimizations. The Go compiler performs nowhere near the level of optimization that LLVM does; LLVM is years and years ahead. However, LLVM is fundamentally a C compiler and so there can be impedance mismatch between Swift and LLVM. Hence SIL. This is what you're seeing, and once the gap is closed then Swift will reap the benefits of the hundreds of optimizations in LLVM.
- igouy 11y agoYou did say "Even when you unsafely compile Swift's code, it doesn't get near." ;-) fannkuch-redux looks near, mandelbrot looks near, n-body… Swift is new to Linux; there's a new compiler snapshot about every 10 days. Swift has only been available on the benchmarks game 3 months for people to contribute programs. Early days :-)
- alblue 11y agoOne surprising performance issue with Swift was identified (and fixed) by IBM recently: https://github.com/apple/swift/commit/259d57bbe7784955108caa88e7222e52134fbfb4 https://github.com/apple/swift/commit/259d57bbe7784955108caa... The problem was that the print operations was being done character-by-character and it resulted in the printing being a significant overhead in the execution of the tests themselves. With this change they saw a speed up of many times simply because it was using buffered output.