Re: 2.6.0-test6
Thanks, I appreciate the information.
You've got some good points. I'd like to find a way to test some of this
'sparc-o y sparc-o' :)
About the only way I could think of to even start would be a bootable random
memory 'tester' for sparc using 32bit _or_ 64 bit reads/writes, and time it.
That's not a real test of how the _kernel_ uses memory, but it would a
starting point.
The same piece of 32 bit code, on a decent cpu arch, will _execute_ at the
same speed. However, you also have to consider the memory requirements,
bandwidth of storage subsystems, caching, etc.
RISC vs. CISC already adds a bit to this, 64 vs. 32 bit makes it more
apparent.
If you had main memory bandwidth equal to core cpu bandwidth, then any
difference between 32 and 64 bit would be so small as to take many moons to
accumulate enough to be measurable. Unfortunately, we don't. The cache helps
_if_ the data set is small enough, or you have good branch prediction. If
either of these fails, then you incur a performance penalty both on the
unneeded bits originally transferred and the addt'l bits during the reload.
I wonder if sparc64 (or 32, take your pick) kernel code has room left for
more optimization in this area?
I really do think this affects debian, in that it's a question for the
kernel/distro in general:
What are the actual effects of a 32 bit vs a 64 bit kernel, performance
wise?
What are the actual effects of 32 bit vs 64 bit userland apps with a 64 bit
kernel, and should developers/maintainers/porters strive towards making
userland 64 bit?
Ditto for memory requirements on both the above questions.
Could we/should we attempt to ifdef more cpu optimizations in?
Would it be possible to actually improve performance overall if we made very
careful use of a particular word length and only used the others when
absolutely necessary?
I'm not trying to offend people here, I'm trying to learn as well as ask
some questions that might (pardon the pun) "sparc" some new ideas or
directions.
Hey, at least I try to be polite, well reasoned, and when possible, give
references to my information sources so people can do their own research as
well.
I would like to add that I truly appreciate the same!
Thanks
Paul
----- Original Message -----
From: "Matthew French" <mfrench@telkomsa.net>
To: "Paul" <paul@techcenter3000.com>; "David S. Miller" <davem@redhat.com>
Cc: <debian-sparc@lists.debian.org>
Sent: Friday, October 03, 2003 8:57 AM
Subject: Re: 2.6.0-test6
> "Paul" wrote:
> > I'm not saying that 32 bit is right for everyone, I am saying that for
> what
> > I do, it would give me a noticeable and measurable boost in speed.
> <snip>
> > Again, if I'm wrong, please explain to me how and/or why. I'm learning
> every
> > day, and I'll learn from anybody that can/will teach me.
>
> I can try. :)
>
> In a 64-bit processor most of the pipelines, memory registers, connections
> to the bus and other circuitry would also be 64-bit. So it effectively
takes
> as many clock cycles to do an operation using a 64-bit application as it
> does using a 32 bit application (if we could still measure things in clock
> cycles). If you have functionality that can use the full 64-bit, which
would
> include floating point operations and file access, then you will get the
> speed improvement. Anyway, on a 64 bit processor it is quite likely that
it
> runs a 32 bit application internally by padding the upper 32 bits with
> zeros - so you have a kind of 64 bit emulation.
>
> Even if you took two identical processors, but one with 32 bit pathways
and
> one with 64 bit pathways, then it is most likely that they would both
> execute 32 bit code at the same speed. If you executed a 32 bit
application
> and a 64 bit app on the same processor, then it is possible that the 64
bits
> would be slower because data must be fetched from memory 8 bytes at a time
> instead of 4 bytes at a time - but this is only a problem if the
connection
> to memory is 32 bit. Since many cache controllers seem to prefetch more
than
> this at a time, it becomes irrellevant.
>
> I think the issue is muddied because most of us remember the upgrade from
16
> to 32 bit Intel processors. This gave a dramatic speed improvement because
> 64kb is not much space for any application. But 4Gb is more than most
> applications need, so the performance improvement of 64 bit from 32 bit is
> not anywhere near as good.
>
> To bring this on topic: I do find Debian on UltraSparc to be a little
slow -
> although fast enough for my needs. This is because most applications are
> compiled for the lowest common denominator. The result is that some of the
> newer opcodes that could bring performance improvements are not being
used.
> Which just goes to show that the 64 vs 32 bit issue is mostly a red
herring.
> I can run a 64 bit kernel, but if SSH does not make use of the processors'
> advanced maths functionality, then it will still be slow.
>
> Look at it this way, a 700MHz Pentium III will whip a 1GHz UltraSparc
III -
> if you are playing Quake, and the Pentium III has a fast new NVidia
GeForce
> compared to the Sparc's 9600 baud serial console.
>
> Which is a very long winded way of saying: forget about 32 vs 64 bit. If
you
> know you need 64 bit, good. If you already have 64-bit, then you will not
> lose anything by using it. And if you really want GLXGears to spin fast,
> consider a good graphics card instead.
>
> HTH,
>
> - Matthew
>
Reply to: