|
From: | Lundberg, Johannes |
Subject: | Re: The Swift Programming Language: what is our position towards this? |
Date: | Mon, 9 Jun 2014 16:55:32 +0900 |
Hi,
I would imagine that it's similar. If you write equivalent code in C and Swift (i.e. function calls and arithmetic, no dynamic dispatch) then they'll generate similar LLVM IR. Swift also differentiates arithmetic operations into cases where overflow means wrap and ones where overflow is undefined. C sort-of does this, but it ties the distinction to unsigned vs signed. This can make optimisation easier, so I'd expect Swift to be faster than C for this kind of thing for quickly written code, and about the same speed for hand-optimised code.
On 5 Jun 2014, at 10:26, Lundberg, Johannes <johannes@brilliantservice.co.jp> wrote:
> I'm curious about the performance of Swift. Perhaps you know more. They claim it is more efficient than Obj-C, but how about C in Obj-C. Now you can write computation intensive code in pure C to avoid any Obj-C overhead I suppose. How about Swift? Are we suppose to write computation heavy stuff in C like on Android or is Swift that efficient that you don't need any other language?
Swift also has explicit checking for overflow. This is possible in Clang via a builtin, but in standard C you rely on the idiom recogniser in the compiler to spot it, and that isn't always reliable. Overflow checking by branch-on-carry is about a factor of 7 faster than overflow checking by arithmetic, so this can be a lot faster than the equivalent C.
The trades in Swift should be roughly equivalent to those in Objective-C: when you use dynamic dispatch, you pay for dynamic dispatch. When you don't use it, you don't pay for it.
David
[Prev in Thread] | Current Thread | [Next in Thread] |