Point of view is everything. You said:
the D5252 is almost a factor of 6 faster than the Rpi for this benchmark I would have said the Rpi is only a factor of 6 slower for this benchmark :-) It's also a factor of 20 smaller (a guess) and uses a factor of 20 less power (also a guess). Regards, Ken On 9/10/2012 10:45 AM, Michael Haberler wrote: > here's linpack figures for the Rpi and an Intel D525. > > the D5252 is almost a factor of 6 faster than the Rpi for this benchmark > > (pull test code with wget http://www.netlib.org/benchmark/linpackc.new) > > pi@raspberrypi ~/tests $ gcc -O linpackc.c -lm -olinpackc > pi@raspberrypi ~/tests $ ./linpackc > Enter array size (q to quit) [200]: > Memory required: 315K. > > > LINPACK benchmark, Double precision. > Machine precision: 15 digits. > Array size 200 X 200. > Average rolled and unrolled performance: > > Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS > ---------------------------------------------------- > 16 0.66 90.91% 3.03% 6.06% 35440.860 > 32 1.33 88.72% 3.01% 8.27% 36021.858 > 64 2.64 88.26% 2.65% 9.09% 36622.222 > 128 5.28 89.58% 3.22% 7.20% 35874.830 > 256 10.56 88.92% 3.12% 7.95% 36170.096 > > > mah@atom:~/src$ gcc -O linpackc.c -lm > linpackc.c: In function 'main': > linpackc.c:78: warning: ignoring return value of '€˜fgets'€™, declared with > attribute warn_unused_result > mah@atom:~/src$ ./a.out > Enter array size (q to quit) [200]: > Memory required: 315K. > > > LINPACK benchmark, Double precision. > Machine precision: 15 digits. > Array size 200 X 200. > Average rolled and unrolled performance: > > Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS > ---------------------------------------------------- > 128 0.96 86.46% 3.12% 10.42% 204403.101 > 256 1.91 87.96% 1.05% 10.99% 206807.843 > 512 3.82 87.43% 2.62% 9.95% 204403.101 > 1024 7.63 87.68% 2.36% 9.96% 204700.631 > 2048 15.26 87.42% 2.82% 9.76% 204254.660 > > > > > > Am 09.09.2012 um 23:35 schrieb Jon Elson: > >> Kent A. Reed wrote: >>> On 9/9/2012 1:54 PM, Jon Elson wrote: >>> >>>> <...> I have not reported any thread latencies for the Beagle. >>>> >>>> >>>> Sorry, Jon. Looking back I see you were talking about how fast one could >>>> drive GPIO pins. My memory is getting rustier by the day. >>>> >> And, mine isn't getting better by the day, either. >>> You've mentioned floating-point performance in the past. Do we have any >>> benchmarking for that? >>> >> There certainly are standard benchmarks that can be run on Linux systems >> that could be >> quite useful. I haven't seen anybody post numbers, but likely they >> already exist on >> the web, somewhere. A quick search didn't show any published results >> comparing >> say, the Beagle Board's OMAP 3430 against an Intel Atom, for instance, >> which would >> be a good comparison. >>>> <...> As for interrupts and timers, if you accept that >>>> you have to add FPGA hardware to the CPU for step generation, encoder >>>> counting >>>> or whatever, then you can have that add-on produce the interrupts for the >>>> RT thread >>>> at any rate you choose. >>>> >>> In my philosophy, Horatio, this is a perfectly acceptable requirement >>> and I look forward to products from you and Peter. I accept as well that >>> they may have to be tailored to specific ARM-based systems for the >>> reasons just mentioned. >>> >> I have built an adapter to connect my boards to the Beagle and emulate >> the IEEE-1284 par port in >> software. It worked, and wasn't horribly slow, compared to a PC. I >> didn't worry about the >> interrupt line, but on the Beagle, at least, ANY GPIO pin can be set up >> as an interrupt. >> I have not even looked at the code required to make that actually work >> (especially since the >> lack of RTAI was the reason work in that direction stopped.) >> >> Jon >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Emc-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/emc-developers > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
