Comparing the CPU of the iPad Pro 9.7 to My MacBook, Surface and 6S (stephencoyle.net)

True, but more modern i7's are not terribly faster from a single threaded perspective: http://www.anandtech.com/show/7003/the-haswell-review-intel-...

And the wattage being burned on newer i7's is probably still several times the ipad pro chip. I think this demonstrates that with a decent compiler (Swift for iOS), ARM chips can be reasonably fast even compared to x86.

I really want an ARM or Power workstation...

I got i7 2600K @ 5Ghz with water cooling. Very hard to find replacement. Test run 16.05s

> For some reason the Swift version took much longer to run on the Macs. Something on the order of 50-65 seconds. I presume I overlooked some optimisation or compiler setting.

A version which shows the iPad performance crushing the Macs, not because of CPU performance but because of some kind of Swift performance regression on desktop, would not have been interesting

And 0.124 s with sqrt(n) and -Os & 0.02 s by interrupting the for... Let's go further than 100000 :)

664579 primes between 0 and 10000000 Time taken = 11.319

Seems like prime will be getting set to false redundantly instead of short-circuiting. Optimizing compilers will catch this. Also not a good test considering that different CPUs might see this with branch prediction, and the results will vary.

I'm not sure there is a basis for this assumption. If there is I can't see one. I also can't see why it would matter.

Edit: Makes more sense with the additional responses.

why ? because the function prime doesn't return when the if condition is false ?

Personal swipes are not welcome on Hacker News.

If you know more, use your superior knowledge to teach people, not put them down. Explaining what can be improved—simply, without snark—would help many of us learn, and would likely evoke an interesting discussion from others.

It doesn't matter much for his test, because the compiler won't optimize it, but one can simplify the loop to only go from 2...n/2+1 e.g. change the line to:

for(int a=2; a<n/2+1; a++)

That would be the obvious optimization, since 2 is your smallest factor, a factor can't be larger than half your number. In actuallity, knowing a little math gives you that if a factor is > the square root of n, there's a factor smaller than that. So:

for(int a=2; a<sqrt(n)+1; a++)

    test for all even numbers only once
    +
    uint last = ceil(sqrt(n));
    for(uint a=3; a<=last; ++a,++a)

Here is my results on a desktop PC from 2010 (i3 CPU 540 @ 3.07GHz × 4):

    g++ -O3 -o prime PrimeChecker.c
    time ./prime

    9592 primes between 0 and 100000
    Time taken = 18.0476

    real	0m18.073s
    user	0m18.048s
    sys 	0m0.000s

It seems the Moore's Law is no longer valid...

I'm running an i7-6700k, on Windows 10 with the MSVC 2015 compiler, my results were 9592 primes between 0 and 100000 Time taken = 12.808 Without optimisations, and 9592 primes between 0 and 100000 Time taken = 10.853 with full optimisations. I would ahve thought it would have been much better. without and with optimisations.

Interesting. C++ and Java are very near on my machine:

    java Prime
    9592 primes between 0 and 100000
    Time taken = 18.484
    9592 primes between 0 and 100000
    Time taken = 18.25
    9592 primes between 0 and 100000
    Time taken = 18.087
    ...

C++: https://news.ycombinator.com/item?id=11412820

    aptitude install openjdk-8-jdk

Yeah. This was another benchmark that found that an earlier Apple CPU got impressive instructions-per-clock on a couple of cryptographic functions (that aren't special-cased like AES): https://zerobyte.io/blog/2014/04/29/benchmarking-symmetric-c...

But those functions also don't really stress-test branch prediction, etc. They use instruction-level parallelism but the control flow and memory accesses are predictable. (That's almost necessary for software crypto; if execution isn't ~constant-time, you risk timing attacks.)

Looking at transistor counts: Apple said the three-core A8X had three billion transistors total. Given Apple's focus on GPU and bringing other components onto the SoC, many of those are not spent on the cores; still, in raw count, it's right up there with Intel's Core-branded CPU+GPU dies, going by a table in Wikipedia.

AnandTech put up a lot of numbers about the A9, including specs like cache sizes and memory bandwidth and benchmarks like Geekbench and SPEC: http://www.anandtech.com/show/9686/the-apple-iphone-6s-and-i...

Seems like, at a minimum, if your intuitions about mobile performance come from early in-order chips, they may not apply to Apple CPUs or even the many Cortex-A57-based SoCs out there. But it also doesn't seem like you can say those chips are up there with Intel ones in general. I guess the evergreen-but-not-wrong conclusion is that to really know your code's performance, you wan to test it on hardware as similar as possible to what it'll really run on.