On Wed Jan 23 10:49:47 EST 2013, [email protected] wrote:
> > Interesting results, thank you!
> > The difference between the Pi and the Sheeva is quite huge,
> > I wasn't excepting such difference. This seems to confirm my
> > initial thoughts regarding the Atom perfs.
>
> that's just for floating point, which the sheeva doesn't have.
> the newer model from the same line does have floating point:
>
> http://www.globalscaletechnologies.com/p-58-mirabox-development-kit.aspx
richard, thanks for the floating point. this is good stuff.
this is better than 100x faster:
; >/dev/null time factor 281476419553081
146.60u 0.01s 148.24r factor 281476419553081
; >/dev/null time /sys/src/cmd/5.factor 281476419553081
1.20u 0.01s 1.22r /sys/src/cmd/5.factor 281476419553081
has anyone been able to recompile gs and then view man pages?
gs dies with a good old-fashioned stack smash.
do there need to be changes to /sys/src/libc/arm?
when i say the pi is slow, i mostly ment in integer performance,
and i/o.
tcptest "burncycles"
pi 5.5MB/s 915.66u 0.02s 924.50r
kw 15.8 463.26u 0.00s 463.34r
(using old tcp)
atom 55.9 457.58u 0.00s 457.68r (8259 eth)
i7 2539 118.0 78.24u 0.00s 78.30r
Xeon X5650 256.0 (10g) 8.79u 0.00s 8.83r
Xeon E31220 112.0 5.64u 0.00s 5.68r
(burncycles calculates the digits of pi using a taylor series
expansion. it uses all the tricks in the book to generate as
few bits of the result per cycle possible, without being verbose,
obtuse, or off task. obviously, it was an accident.
the very fast machines have the advantage of non-emulated
vlongs, running amd64 kernels)
- erik
