For Swift development, is an nMP fastest?

[cerberusss]

My current employer gave me a base model 15" rMBP which is a really nice machine. However, our team is currently developing a Swift application with Core Data. When using mogenerator, this results in a lot (~250) of Swift files with a single class in it. Compared to Objective-C code, Xcode takes a looooooong time compiling, minutes even for a minor change.

I was wondering, are there developers here who can tell me if the nMP is really the fastest for this kind of task? Or perhaps the latest retina iMac is better for that?

 

[mjohnson1212]

Xcode was re-compiling all swift files before instead of supporting incremental building like it does for objective c.
That's been added and with whole module optimization on building swift is a lot faster.

Xcode can use all the cores you have available to compile the code so it will go faster on a nMP if it has more cores than the rMBP/iMac.

I use a 6 core nMP and it's noticeably faster than the other 4 core macs I have. Not a lot faster but enough that it is noticeable if you are building lots of code. My builds include lots of objective c libs and some swift source but not 250.

To answer your last question yes in general a nMP would be faster if it has more cores and you're building a lot of code.

That being said I develop on my '11 17" macbook pro all the time and it takes longer on a full build but most of the time it's plenty fast so your rMBP should be fine.

 

[deconstruct60]

Compared to Objective-C code, Xcode takes a looooooong time compiling, minutes even for a minor change.

The machine the root cause or is parallel invocations of the compiler being blocked?

http://stackoverflow.com/questions/...-files-in-parallel-if-you-have-more-cpu-cores

http://stackoverflow.com/questions/29135197/how-to-track-down-slow-compiling-swift-code

Does Swift have precompiled header support? If not and a decent number of includes then a high file count means ridiculous amounts of redundant work to be done.

I was wondering, are there developers here who can tell me if the nMP is really the fastest for this kind of task? Or perhaps the latest retina iMac is better for that?

If the file compiles are huge RAM consumers then a nMP will scale to higher RAM capacities. Higher core count means wider parallel compiles (if don't bump into RAM/caching constraints)

 

[Gurpartap Singh]

I've heard similar complaints from developers on iMac 5K with i7 processor. Although, no doubt, anything faster than base rMBP will be useful in some manner. It's the Swift compiler which isn't fully optimized yet. Maybe things are changing with yesterday's announcement of Swift 2.

I can't say for performance on nMP in particular, since I haven't heard any first hand feedback about it. However, as mentioned by others, more cores help with compile times. I would, too, like to hear more from developers using nMP. Perhaps we can use an open source Swift project's (that utilizes most of its advanced features) compile time as a benchmark? How about ReactiveCocoa 3.0?

 

[IowaLynn]

I've heard similar complaints from developers on iMac 5K with i7 processor. Although, no doubt, anything faster than base rMBP will be useful in some manner. It's the Swift compiler which isn't fully optimized yet. Maybe things are changing with yesterday's announcement of Swift 2.

I can't say for performance on nMP in particular, since I haven't heard any first hand feedback about it. However, as mentioned by others, more cores help with compile times. I would, too, like to hear more from developers using nMP. Perhaps we can use an open source Swift project's (that utilizes most of its advanced features) compile time as a benchmark? How about ReactiveCocoa 3.0?

Where have I read about how Fortran and C++ compilers running as GPGPU and how compilers were perfect for massively parallel computing?

My 4.4GHz 6-core i7 with a couple nice GPUs perhaps??

There was talk back in 2011 about better graphic compilers with MS backing and others to improve upon code and with less hand-wringing tweaking needed to generate optimized code whether OpenCL or even CUDA to run on more GPUs. Is this the fruit of that?

 

[cerberusss]

The answers on StackOverflow didn't help me much. It's just the total amount of small files that the project consists of, not any specific file. Also, we have a bunch of classes that are IBDesignable. These got compiled again and again, and it got so bad we got rid of those.

I've successfully worked on a MacBook Air, when doing an ObjC project. So it is really Swift.

I hope that Xcode 7 and Swift 2.0 will be better, because I wasn't all that impressed with the better incremental compiling support in the current Swift compiler. It got better, but it's still pretty bad. However, from what I gather here, just throwing more cores at the problem will help but not remove the problem.

Oh man, I love this forum

 

[deconstruct60]

...These got compiled again and again, and it got so bad we got rid of those.

I've successfully worked on a MacBook Air, when doing an ObjC project. So it is really Swift.

It is the age of Swift. It isn't a hard property of the language. If you worked on the same ObjC project with Apple's gcc v3 ( or v2?) fork you'd be crying the same blues.

ObjC/C/C++ has #include and Swift has "import". At the compiler semantic analysis level it isn't much of a difference if have to process from almost scratch every time see the same include/import.

If you load up a Swift REPL (read, eval, print , loop) and toss the contents of one of those small files at it, it will likely go quite fast if the REPL has preloaded the contexts you are importing already.

Sorting things out with the huge dependencies and each compiler is independently running in parallel is more work.

 

[cerberusss]

It is the age of Swift. It isn't a hard property of the language.
Sorting things out with the huge dependencies and each compiler is independently running in parallel is more work.

Yeah, I agree. It might be interesting to just cat those small files to 1 bigger file, if things don't get better in Xcode 7.

I was also simply curious how popular the nMP is among developers.

 

[cerberusss]

For people interested, I found a guy who posted a review on his blog, specifically benchmarking a small and large Xcode project:

http://ikennd.ac/blog/2014/07/mac-pro-review-developer-edition/

 

[deconstruct60]

I was also simply curious how popular the nMP is among developers.

An admittedly small sample size but there are some pictures of the folks who won the Apple design awards this year and some of their development gear ......

https://developer.apple.com/design/awards/

Not a single MP (new or old ) in sight. For the most part they all look modern Silicon Valley hipster chic locations (even though not all in SV ). Maybe the MPs are in the room where folks actually have paper, books, and stuff on their desks and everything isn't aseptic clean.

The notion that a MP is required to produce a very good OS X or iOS program is grossly overblown.

It probably varies by work environment location ( open work area , cubes , or office with a door ) , team policy dynamics ( high network traffic on a centralized wired network or semi-autonomous git repositories that roam where ever the developer choses to work ) , and broad/narrow targeted user base ( development for the 1% or normal folks ).

I think this forum is skewed with folks who spend "company" money to buy their development systems. So the notion of needing maximum hardware to get work done works to justify the spend as much to satisfy the actual requirements.

 

[deconstruct60]

For people interested, I found a guy who posted a review on his blog, specifically benchmarking a small and large Xcode project:

http://ikennd.ac/blog/2014/07/mac-pro-review-developer-edition/

Not really surprising. Disk I/O is contributing major factor. The RAM disk is helping. He has an old (relative to 2015), smaller SATA SSD up against a 1 TB ( max internal raid) x4 PCIe SSD. If you get a 2015 MBP with 2015 era 1TB drive that playing field is at least leveled ( NVMe SSD might help with the highly random I/O generating by wide spectrum file streaming ). Max'ed out RAM in a MBP a RAM disk can cover small-medium sized projects if pressed. The additional 2 cores help but they aren't the sole differentiating factor.

RAM disk doesn't make the debugger faster and editing/writing code is rather risking on a RAM disk. This compile time is about a 1/3 of the read/write/edit , compile, and debug cycle.

 

[cerberusss]

An admittedly small sample size but there are some pictures of the folks who won the Apple design awards this year and some of their development gear ......

https://developer.apple.com/design/awards/

Not a single MP (new or old ) in sight. For the most part they all look modern Silicon Valley hipster chic locations (even though not all in SV ).

That's a very clever way of gauging its popularity. Indeed, not a single one in sight... That does say something.