discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The Swift Programming Language: what is our position towards this?


From: David Chisnall
Subject: Re: The Swift Programming Language: what is our position towards this?
Date: Thu, 5 Jun 2014 10:35:37 +0100

Hi,

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?

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.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]