Re: [9fans] 9pi + apple keyboard

[erik quanstrom <quanstro@quanstro.net>]

> > 	; >/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
>
> Umh how does 'factor' relate to a FPU?
> I don't have a plan9 running there, but the gnu 'factor' runs in 2.2s in
> a raspberrypi, and 0.05s in a sheevaplug, here.

factor on plan 9 uses floating point heavily.  rpi has floating point
hardware, and the sheeva plug does not.  (at least according to
the nda docs on the processor i read.)

> > (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)
>
> What are these emulated vlongs? Would that mean an atom computer would run
> relevantly faster i686 code over x86_64 code?

i think i said the opposite.  amd64 code heavily running vlongs
would run faster in long (64-bit) mode.  this is because since the registers
are 64-bit wide, normal 64-bit arithmatic can be computed directly
with machine instructions.  with a 32-bit machine, the compiler needs
to emulate a 64-bit operation since the registers available are not wide
enough.

(iirc, there were no atoms in 64-bit mode in the list.)

- erik