From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 26 Jan 2013 12:59:21 +0100 From: =?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20130126115921.GN2324@vicerveza.homeunix.net> References: <510005B3.3050407@yahoo.fr> <4657d4c2cf46efd4ec1ede334e4d2bdc@kw.quanstro.net> <9aaa301130543ac6bc01a5b08a6133be@ladd.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <9aaa301130543ac6bc01a5b08a6133be@ladd.quanstro.net> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] 9pi + apple keyboard Topicbox-Message-UUID: 0f17cbb4-ead8-11e9-9d60-3106f5b1d025 On Wed, Jan 23, 2013 at 04:10:48PM -0500, erik quanstrom wrote: > On Wed Jan 23 10:49:47 EST 2013, quanstro@quanstro.net 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. > >=20 > > that's just for floating point, which the sheeva doesn't have. > > the newer model from the same line does have floating point: > >=20 > > http://www.globalscaletechnologies.com/p-58-mirabox-development-kit.a= spx >=20 > richard, thanks for the floating point. this is good stuff. > this is better than 100x faster: >=20 > ; >/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. > (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 ru= n relevantly faster i686 code over x86_64 code? Regards, Llu=EDs.