On Thu, Jan 30, 2003 at 04:24:03PM +0100, Martin Husemann wrote:
> On Thu, Jan 30, 2003 at 02:34:45PM +0100, Bernd Walter wrote:
> 
> > [103]cicely21# ./blah 
> > 69.732u 0.129s 1:11.98 97.0%    0+0k 1+1io 0pf+0w
> 
> My 100 MHz Krups needs 26 seconds.
> My 300 MHz ultra sparc needs 6.59 s.
> My 400 MHz PII 0.89 s.

I don't tell you how long it takes on one of my sun3 :)

> So gcc sucks (for sparcs at least), sparcs are dog slow, old Intels get 7.5 x
> the performance at the same clock frequency.

I know.
Has anyone tried to recompile the given code with a gcc 3.2?
I've learned from FreeBSD alpha, that the resulting code for non-x86
CPUs is often much better.

> Which of these is a suprise for you?

Well the fact is that I don't know what happens behind the scene when I
call this function.
I hoped this could have been a problem with my configuration and OpenSSL
not trusting my random numbers, or something like that.

On Thu, Jan 30, 2003 at 05:25:04PM +0100, Martin Husemann wrote:
> On Fri, Jan 31, 2003 at 02:53:17AM +1100, matthew green wrote:
>
> >    My 100 MHz Krups needs 26 seconds.
>
> > did you use "gcc -mv8"?

No - the base system is a plain binary install, which I asume to be
compiled v7 aware.

> No, stock userland relying on the ld.elf_so preload trick for v8 CPUs.
> So theres a little bit to gain for this timing. Note, however, that
> the sparc64 machine nearly is a linear improvement on this value, so
> I don't expect much.

Are you saying that there is automaticaly v8 and v7 code compiled in,
which is choosen at runtime?

> Compiled for v7 CPUs it should be *much* slower.
> This machine needs 246 seconds:
> mainbus0 (root): SUNW,Sun 4/75
> cpu0 at mainbus0: cache chip bug; trap page uncached: CY7C601 @ 40 MHz, TMS390C602A FPU
> cpu0: 64K byte write-through, 32 bytes/line, hw flush: cache enabled

That doesn't mean, that the difference is because of v7 vs. v8.

-- 
B.Walter              COSMO-Project         http://www.cosmo-project.de
ticso@cicely.de         Usergroup           info@cosmo-project.de