Going from A to B is exactly an example of a task that can't be solved in parallel fashion. On the other hand, if you needed to merely cover N miles, then a pool of cars would work just fine.
Going from A to B is exactly an example of a task that can't be solved in parallel fashion. On the other hand, if you needed to merely cover N miles, then a pool of cars would work just fine.
To use another car analogy. Counting clock speed is like counting the cars max RPM instead of actually measuring the performance. And then they have totalled the max RPM figures as if they have have 90,000RPM engine.
http://home.wlu.edu/~whaleyt/classes/parallel/topics/amdahl....
I should have referenced Amdahl's law in the previous post but didn't want to misspell it and bother to look it up.
*Infinite numbers exist of both parallel and serial computing requirements. Practically there will almost always be additional cost in parallel implementation even if the extra is insignificant such as higher start up cost and coordination for shutdown.
http://en.wikipedia.org/wiki/Gustafson%27s_Law
Gustafson and Barsis pointed out that Amdahl assumed a fixed input size. If instead you grow the problem size along with the number of processors, the speedup from parallelism grows indefinitely. Of course, like Amdahl, they assume perfect load balancing and don't factor in communication overhead. But parallel still beats the pants off of serial if we want to keep solving larger and larger problems.
People = threads and cars = cores.
You can nitpick as much as you want, but for a lot of applications it's perfectly OK to sum up the frequencies. A job that can be spread over 8 cores will be executed at about the same time as it would execute on a single core at 8x the frequency
Plus there's absolutely no precedence for using clock frequencies cumulatively like this anyway (which I've already demonstrated with my multi-core CPU example), thus the figures Adapteva are touting are not only scientifically and mathematically inaccurate, but also breaking established advertising convention too.
Thus their figures are incorrect - period. So accusing us of nitpicking incorrect figures is just plain dumb when there's absolutely no merit to the 13GHz figure what-so-ever.
[edit]
And it's a sad day for geeks worldwide if discussing the correct usage for scientific measurements is considered nitpicking. Had this been Fox News or the Daily Mail, then your view point could be forgiven. But this is a hacker forum, so I'd expect a higher level of technicality rather than simply ignoring counterarguments in such a dismissive manner. :(
A better angle would be - given the project and its goals, do you really think it's worth putting them down for something as trivial (and technically correct) as this -
Once completed, the Parallella computer should deliver
up to 45 GHz of equivalent CPU performance
That, as they say on TechCrunch, is a dick move. If anything, they deserve a pat on a back and a donation.If you had even the slightest idea about how cores are rated and the complexities of multi-threaded development, then you'd realise that summing the frequency of the cores is completely inaccurate. Hell, don't you think Intel would be doing this with their multi-core processors if it was a legitimate statistic? (a point I've made several times now but you keep ignoring).
You've been told by a multitude of people what the correct measure of cumulative processing power is, and instead you're still holding onto the same myth which the clickbait headlines are perpetuating. So really, you're just reinforcing my point about how they shouldn't be using such a dumb statistic because people who don't know any better will fall for it.
Anyway, and FYI, core frequency isn't even a good measure of CPU performance on single core systems. A 1GHz RISC CPU will perform vastly differently to a 1GHz CISC. Then you have the plethora of RISC architectures; and even on x86, different CPUs will have different co-processors, caching, pipelining and even additional instructions, thus will perform differently on different stress tests.
So crudely summing clock frequencies on a cluster is about as accurate a description of performance as remarking on the colour of the motherboard. But let's not let a pesky thing like science get in the way of our deeply held beliefs ;)