www. O S N E W S .com
News Features Interviews
BlogContact Editorials
.
The best hardware to build with Swift is not what you think
By Thom Holwerda on 2017-03-15 23:22:09

Some interesting figures from LinkedIn, who benchmark the compiling times of their Swift-based iOS application. You'd think the Mac Pro would deliver the fastest compiles, but as it turns out - that's not quite true.

As you can see, 12-core MacPro is indeed the slowest machine to build our code with Swift, and going from the default 24 jobs setting down to only 5 threads improves compilation time by 23%. Due to this, even a 2-core Mac Mini ($1,399.00) builds faster than the 12-cores Mac Pro ($6,999.00).

As Steven Troughton-Smith notes on Twitter - "People suggested that the Mac Pro is necessary because devs need more cores; maybe we just need better compilers? There's no point even theorizing about a 24-core iMac Pro if a 4-core MBP or mini will beat it at compiling."

 Email a friend - Printer friendly - Related stories
.
Read Comments: 1-10 -- 11-20 -- 21-30 -- 31-36
.
Comment by Alfman
By Alfman on 2017-03-16 03:49:10
Thom Holwerda,
> As Steven Troughton-Smith notes on Twitter - "People suggested that the Mac Pro is necessary because devs need more cores; maybe we just need better compilers? There's no point even theorizing about a 24-core iMac Pro if a 4-core MBP or mini will beat it at compiling."

You know, I've said it before, unless you have a highly localized CPU bound process, you're usually better off with the faster clock rate.

Ironically the "higher end" systems with more cores often perform worse because the law diminishing returns kicks in at a relatively low core count whereas CPU speed is proportional to clock speed (if you look at the clock speeds on those MacPros you'll see they are lower).

People like the idea that moores law can continue by replacing clock speed gains with core count gains, but generic software does not scale well that way.
Permalink - Score: 3
.
Comment by joekiser
By joekiser on 2017-03-16 03:51:39
I don't have a LinkedIn so I can't see the results, but my comment based on summary is this: That is not a $1399 computer. Mac Mini hasn't been updated in 2+ years. 2012 i7 was faster than the 2014 i7.

So chances are, a sub-$1000 5 year old machine is better than a current Mac Pro for Swift compilation.
Permalink - Score: 3
.
seems OSX is the problem
By unclefester on 2017-03-16 05:39:46
An Apple engineer discusses the problem of running multi-core application on Macs.

https://www.quora.com/Is-it-the-O...
Permalink - Score: 3
.
RE: Comment by Alfman
By Earl C Pottinger on 2017-03-16 06:27:21
I write code to run multi-threaded in Haiku. and one of the two things I have to struggle with is to get the inner loops to fit inside the L1 cache of each CPU so the threads run as fast as possible.

What I find is a harder problem, and sometimes unsolvable is the data access of the different threads, it is rare that the threads want to work on the same data at the same time resulting in each thread invalidate the L2 and L3 caches.

There is a way to lock certain data into the cache but I don't think it helps with my programs. I just wish I had large caches in my I7.

Edited 2017-03-16 06:32 UTC
Permalink - Score: 4
.
RE: Comment by Alfman
By oiaohm on 2017-03-16 06:43:46
http://www.phoronix.com/scan.php...

The reality is law of diminishing returns is not straight forwards as the ryzen proves.

People like the idea that moores law can continue by replacing clock speed gains with core count gains, but generic software does not scale well that way.

Some generic software scales in ways that are suitable for more cores. But a lot of software does not. So this really should be "most generic software does not scale well that way".

Lot of software development for Linux is accelerated by more cores but that is because the build system is designed in lot of the cases to exploit multi cores. So OS X development system is not designed to exploit multi cores to the best.
Permalink - Score: 3
.
RE[2]: Comment by Alfman
By mojmir on 2017-03-16 11:16:24
wouldn't it be marvelous to have on-chip addressable local memory to be under control of programmer, like the 256KB local storage in Cell (ps3)?
Permalink - Score: 2
.
RE[3]: Comment by Alfman
By Kroc on 2017-03-16 11:36:15
The XBONE has 32MB of EDRAM directly on the CPU die, and Intel make chips with 128 MB of EDRAM. I think this is the way things will slowly go as having some memory that's thousands of times faster than system RAM, but isn't CPU-controlled cache, is a massive win for software that can use that space intelligently; games are a very good place for that understanding to be born.
Permalink - Score: 3
.
RE: Comment by joekiser
By laffer1 on 2017-03-16 12:35:14
A Mac pro is a 2013 era machine too. It hasn't been refreshed. The other issue here is that depending on the setup of their software, the compiler can't optimize well. If they have most of there code in only a few files, it can't be done in parallel easily.

If you test compiling something huge like say the linux kernel or FreeBSD, you can see parallel builds are faster up to the point you're I/O blocked.

It's certainly possible the swift front end for the compiler is not optimized for parallel builds too.

All we've proved is that yesteryear apple tech is slow. If tim cook would only refresh the mac line like he's supposed to. No one sent him the memo that tech companies have short upgrade cycles.
Permalink - Score: 4
.
RE[4]: Comment by Alfman
By jockm on 2017-03-16 13:22:57
Back in the day RAM was faster than the CPU. This is part of the reason (along with chip complexity) why the 8-bit CPUs had so few registers, there wasn't really a penalty for going out to RAM.

The ultimate expression of this was the TMS9900 CPUs (used in the TI-99/4). It was a 16 bit CPU with 16 registers... that were all stored in RAM. IIRC only the instruction counter and flags, and the address of the register window, were kept internally to the chip.
Permalink - Score: 2
.
RE: Comment by Alfman
By Bill Shooter of Bul on 2017-03-16 14:40:21
Well, the article says they did benchmark on the two systems and at one point they found the mac pro was better, and it seemed like more cores was better than higher clock speed.

Apple updated xcode, and now there are wonky results detailed in the article.
Permalink - Score: 2

Read Comments 1-10 -- 11-20 -- 21-30 -- 31-36

No new comments are allowed for stories older than 10 days.
This story is now archived.

.
News Features Interviews
BlogContact Editorials
.
WAP site - RSS feed
© OSNews LLC 1997-2007. All Rights Reserved.
The readers' comments are owned and a responsibility of whoever posted them.
Prefer the desktop version of OSNews?