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
.
RE[2]: Comment by joekiser
By joekiser on 2017-03-17 20:21:27
It wants me to register, both here and at work. I left LinkedIn years ago after they pulled a stunt that tricked people into providing their email passwords so that LinkedIn could read all the contacts and spam them.
Permalink - Score: 2
.
multi-threaded coding
By Earl C Pottinger on 2017-03-18 02:06:55
In-fact I sometimes just think for days even weeks about how to solve a problem by making it multi-threaded.

Two things have made me do this.

(1) I wrote an digital/analog scope program for Haiku, each function/control ended up having a separate thread, before I knew it I had a multi-thread program that not only was fast and smooth to use. I now want all my programs to be like that.

(2) While writing a program to search a large hash-space I ended up with a single threaded program that took an entire weekend (54 hours) to run. That meant every time I tried the improve the hashing parameters I had wait two+ days to get my test data. Finally I looked at how I handled the search and the tests, I broke the searches in multiple range search threads and then had those pass hashes that passed the first tests to a final thread that did the rest of tests. Running as 16 threads plus the final testing thread the runs took less than 2 hours each.

However note. to get that speed-up I have to realize a whole new way to process the data.

Multi-threading is hard not because it is hard to do, but because you have forget the old methods to solve a problem and think of brand new methods that have very little to do with how the old methods worked.
Permalink - Score: 1
.
RE: multi-threaded coding
By Alfman on 2017-03-18 02:26:05
Earl C Pottinger,

> (2) While writing a program to search a large hash-space I ended up with a single threaded program that took an entire weekend (54 hours) to run. That meant every time I tried the improve the hashing parameters I had wait two+ days to get my test data. Finally I looked at how I handled the search and the tests, I broke the searches in multiple range search threads and then had those pass hashes that passed the first tests to a final thread that did the rest of tests. Running as 16 threads plus the final testing thread the runs took less than 2 hours each.

For the sake of discussion, do you mind sharing the problem and requirements you were trying to solve? The thing about using hashes for search is that's it's usually very fast (ie O(1)). A binary search is O(log(N)) and even that should converge fairly quickly. What exactly were you searching (assuming you don't mind my asking)? Do you mean iterating a hash over values like bitboin?
Permalink - Score: 2
.
RE[2]: multi-threaded coding
By Earl C Pottinger on 2017-03-19 04:39:46
Hello, I don't think you will find my use useful.

What I needed were a set of hash value to fill a S[BOX] where the values in the S[BOX] when any two values XOR together would not generate a value that was also in the S[BOX]. Add on the factor that the values were also doing a cit rotation thru a 32-64 bit hash value and I had to do a lot of testing for each value.

It did not end there I also wanted each hash value to flip a min. number of bits so I also needed to do bit counting for each tested value.

I hope that is clear.
Permalink - Score: 1
.
RE[3]: multi-threaded coding
By Alfman on 2017-03-19 17:54:51
Earl C Pottinger,

> I hope that is clear.


So you were effectively creating your own hash and iterating over it to test some properties then? That makes more sense, it's not really what I was picturing, haha.

Sounds fun. I assume you were searching a 32bit space then? Brute forcing a 64bit hash is considerably harder, 128bits probably impossible.

I've implemented standard crypto hash algorithms but I've never designed my own. I've designed some random number generators, which are similar, but that was to initialize random motion vectors, not really anything dependent on strong hashing requirements.
Permalink - Score: 2
.
RE[4]: multi-threaded coding
By Earl C Pottinger on 2017-03-20 02:55:54
The 32 bit version I tested all possible values, I did not do a true 64 version just used 64 variables.

I was playing around with 48 bit hashes, and testing random() numbers. It did work, and the larger search space found valid hashes faster. But the original 32 bit hashes worked fine as I found over two million valid numbers and I only needed 256*4096 values (enough to hash an entire disk data block).

What was fun was when I realized how to do it in a multi-threaded way by throwing out my old assumptions.
Permalink - Score: 1

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?