[swift-users] Huge difference in speed in Array<Class>/Array<Struct> on OSX/Ubuntu platform with same? toolchain

Mon Feb 1 16:02:15 CST 2016

on Fri Jan 29 2016, Trent Nadeau <swift-users-AT-swift.org> wrote:

> I haven't looked at the bridging code yet, but is it possible that the
> overhead could only be incurred on the first conversion to NSArray? That
> way if you don't use that functionality it's consistent across platforms,
> and if you do use it, you get an initial O(n) hit and then O(1)
> afterwards.

There's no overhead on conversion to NSArray.  The overhead applies to
all arrays aren't statically known not to be backed by a NSArray that
comes from ObjC.  In practice, that's all Arrays whose Element type is a
class or ObjC existential.  The overhead is due to a branch on each access,
where we decide whether to take the fast path (the backing storage was
created by Swift, a.k.a. a "native" buffer) or the slow path (the
backing storage is an otherwise unknown NSArray).  There is a similar
slow path for a deferred type when accessing elements in the results of

  someArrayOfBase as [Derived]

We have discussed other ways to slice the efficiency and usability
tradeoffs here; if you'd like to talk about that I'd recommend bringing
it up on the swift-evolution list.

> On Fri, Jan 29, 2016 at 2:27 PM, Joe Groff via swift-users <
> swift-users at swift.org> wrote:
>
>> Arrays of class type have additional overhead on Apple platforms due to
>> the NSArray interoperability. You can use ContiguousArray<Class> if you
>> don't need to interoperate with Objective-C to get more consistent
>> performance.
>>
>> -Joe
>>
>> On Jan 28, 2016, at 10:30 PM, Sergey Kuratov via swift-users <
>> swift-users at swift.org> wrote:
>>
>> Hello,
>> I've just started to work with Swift (have C++ background) and try to make
>> some tests to avoid problems in design. But from beginning I met very
>> disappointing case.
>>
>> 1. So I have 2 similar computers:
>> - Ubuntu 15.10 with clang and Swift-2.2 dev 2016.01.25 for Ubuntu 15.10
>> - iMac with OSX 10.11 and  Swift-2.2 dev 2016.01.25 fro OSX (switched to
>> this toolchain)
>>
>> 2. Took extremely simple source code from n-body sample
>> <http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=swift&id=3>
>>
>> 3. Set Release version with -Ounchecked -whole-module-optimization for
>> both computers and get results:
>>
>> Ubuntu - 8.4 sec
>> OSX - 167.3 sec
>> Was demolished by results
>>
>> 4. Changed "class Body" to "struct Body" and get another results:
>>
>> Ubuntu - 12.2 sec
>> OSX - 10.0 sec
>> Again was deeply moved by results
>>
>> 5. Added
>> *let arrPtr = UnsafeMutablePointer<Body>(bodies)*
>> before loops and used arrPtr instead of bodies in loops. Got new result:
>>
>> For "class Body" variant:
>> Ubuntu - 7.3 sec
>> OSX - 11.1 sec
>>
>> For "struct Body" variant:
>> Ubuntu - 6.7 sec
>> OSX - 8.8 sec
>>
>> I believe something wrong with Swift compiler/optimizer if for the same
>> x64 processor same toolchain generate very different code. Especially in 1
>> case with "class Body" on OSX platform - I guess it's bug. Can somebody
>> comment results ?
>>
>> PS: Forgot to say - similar Java program n-body in Java
>> <http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=java&id=2>
>> takes 6.5 sec on Ubuntu and 9.2 sec on OSX
>> _______________________________________________
>> swift-users mailing list
>> swift-users at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>>
>>
>> _______________________________________________
>> swift-users mailing list
>> swift-users at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>>

HTH,

-- 
-Dave