On Mon, 2012-09-10 at 16:41 -0400, Kent A. Reed wrote: > 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 > > > > > I wanted to point to http://elinux.org/Rpi_Performance earlier but I > couldn't remember where I had seen the numbers. > > They reported marginally (ca 15 percent) better LINPACK performance with > their RPi at 700MHz and managed ca 60KFLOPS by overclocking to 1000MHz. > > Your numbers also don't seem out of line with > http://www.ptxdist.org/development/kernel/arm-benchmarks-20100729_en.html, > although they tested a BeagleBoard. > > I remember feeling ok in the Spring about my BeagleBoard-XM because I > knew the Raspberry Pi ARM11 cpu uses the older ARMv6 instruction set*; > then I felt queazy when I realized the RPi includes VFP; now I am > bemused to read the following (from > http://vanshardware.com/2010/08/mirror-the-coming-war-arm-versus-x86/ > which tested yet another ARM system)
A most interesting link! It does look like ARM8 does need to pick up some processing power. The really interesting thing was the embedded crypto capability of a couple of the chips. Too bad we don't need that kind of power. ;-) Still the only thing that really counts is enough speed to handle motion. We should be able to pass the GUI off to a dedicated X-term and likewise boards from Jon and Peter are clearly capable of driving the steppers/servos and handling discrete I/O. Better cpu's seem to be coming; the tough part is in the waiting. :-) Dave > > > Oddly enough, during our performance optimization experiments, Neon > > generated the same level of double-precision performance as the VFP, > > while doubling the VFP’s single-precision performance. When we asked > > ARM about this, company representatives replied, “NEON improves FP > > performance significantly. The compiler should be directed to use NEON > > over the VFP.” > > > Finally, from mathtest.c comes this 2004 comment by Paul Comer (drawn > from notes by Fred Proctor) > > > /* > > math functions are: > > > > extern double sin(double); used in posemath, siggen, & > > noncartesian kins > > extern double cos(double); used in posemath, siggen, & > > noncartesian kins > > extern double tan(double); not used in RT > > extern double asin(double); not used in RT > > extern double acos(double); used in posemath & noncartesian > > kins > > extern double atan2(double, double); used in posemath & noncartesian > > kins > > extern double sinh(double); not used in RT > > extern double cosh(double); not used in RT > > extern double tanh(double); not used in RT > > extern double exp(double); not used in RT > > extern double log(double); not used in RT > > extern double log10(double); not used in RT > > extern double pow(double, double); not used in RT > > extern double sqrt(double); used in tc, segmot, & noncartesean > > kins. > > extern double ceil(double); used in segmot & emcpid > > extern double floor(double); used by siggen & segmot > > extern double fabs(double); used a lot in RT > > extern double ldexp(double, int); not used in RT > > > > extern double sincos(double, double *, double *); Is called at four > > places in > > posemath - None of the > > resulting > > functions are used in > > EMC. > > Extras: > > > > extern int isnan(double); Not used directly in RT - But is > > called > > by several (all ?) of the floating > > point > > math functions. > > */ > > Obviously, this ignores the pedestrian functions like add, subtract, > multiply, divide, negate, and compare, but do you suppose this is still > an accurate accounting of the floating-point math functions used in > LinuxCNC? > > Regards, > Kent > > > ------------------------------------------------------------------------------ > 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
