Guess who's gone all 64bit!!!!!

[Karlos]

@bloodline

I can appreciate the sense of anticlimax. Consider it, other than supporting more than 4GB of linearly addressable physical memory, what does 64-bit do for you anyway?

I mean really, when it comes to instruction processing, many CPU's have supported 64-bit operands and data buses for a long time. Heck, even the Pentium2 can do 64-bit integer operations.

[Karlos]

mdma wrote:

Sh!t loads of extra registers is what gives it it's speed. Oh, and the 1MB of cache on-die. :-)

64bit Linux is a hell of a lot faster on this Athlon64 3200+ of mine than 32bit Linux is.

Here you demonstrate my point exactly. The performance increase is sod all to do with the "64-bitness" of the CPU. Rather it is down to having a new core architecture, more registers, new instructions and a larger cache.

All the 64-bit really refers to is the addressable space - and one assumes all the internal/external buses.

[Karlos]

T_Bone wrote:
I want a **TRUE** 64 bit CPU!!!

64 bit ASSEMBLY OPCODES baby!! YEA!
(with that many opcodes, assembly would pretty much be a high level language)

Well, suppose you made a super RISC load/store architecture where you had, eg 65536 integer and 65536 floating point registers, you could easily have 64-bit opcodes. 16-bits for the instruction and up to 16-bits each for each register definition :lol:

[Karlos]

mdma wrote:

I wasn't disagreeing with you, I was trying to demonstrate your point.

No, no, I realise that. I was just connecting your post and mine :-)

[Karlos]

bloodline wrote:

Hmmmm, you would probably just have a 64K register file...

Well, you could still have L2 cache, but you'd have less need of L1 cache :lol:

I dread to think how difficult to code such a system would be implement, let alone code for. It would be difficult to manage such a huge register file effectively in a multitasking OS.

Still, whilst we're being silly :-D...

Mind you, if you had a default 'offset' register that allows your definition of 'register 0' to be offset to any register in the file, you could implement a sort of "fixed register size per task" kernel, where each task would have it' own block of X registers. Once the register file fills, youd page out the ones for those tasks that arent doing anything.

Other than that, each task would just see eg 32 registers belonging to it that the OS almost never has to save/restore as part of task switching.

I wonder what the upper limit is for a sensible 'directly accessible' (that is not including shadowning and forwarding) register count?

I think PPC's 32 is more than enough, really...

[Karlos]

I expect it would harm the JIT. After all, Athlon64 "64-bit native" code has about as much in common with the original x86 as PPC does :-) A new JIT would need to be developed.

I wonder how much of the speed increase on 64-bit windows is down to lower latency of system calls (assuming 64-bit system code runs faster for all the various reasons mentioned) ?

[Karlos]

@mdma

Remember that x86 has used a RISC style core for a long time. There are actually a very large number of rename registers as 'aliases' for the main ones. You can't use them directly, of course, but they basically allow greater parallelism when subsequent instructions don't depend on the immediate outcome of previous ones.

The AMD64 uses this same trick too. It has a lot more than 16 registers using a similar rename scheme. Even the PPC, with 32 registers uses rename mechanisms to help eliminate stalls when multiple instructions executing concurrently depend on each other. Even the venerable 603e has five rename registers (basically amounting to one each per functional unit in the core).

What it basically means is that x86 and AMD64 both are running from their registers and L1 cache most of the time. Having 16 registers just means you can write better code where the programmer/compiler can take advantage of more registers. If you imagine an algorithm on x86 might spend a reasonable amount of time juggling register variables to/from memory (usually the cache) during a loop, the same algorithm for AMD64 could simply keep the important values in registers, cutting down the number of instructions required to perform the overall operation. This is where you will see some speedup.

[Karlos]

bloodline wrote:
I think the speed up from 32bit to 64bit that mdma and myself are experiencing is simply due to more elegant optimisation allowed for by 16 registers...

Which is basically what I was trying to say, but you managed a lot better job of it :lol:

[Karlos]

Surely you need 64 registers to complete the 64ness of it all? :-P

[Karlos]

bloodline wrote:

Well my chip is a 90nm one and they have built up quite a reputation for Over Clocking... I noticed that mine ran 23C... I don't think I've ever seen a CPU run so cold!... I decided to crank up the Speed... :-D

Try it without any cooling and see how hot it gets...


*disclaimer : don't do this, 'tis a silly idea.

[Karlos]

mdma wrote:

Well, I never thought I'd hear myself syaing this, but 64bit windows with the latest 64bit radeon drivers feels just as responsive on this Athlon 64 3200+ with 1MB L2 cache as MorphOS on my Peg G3.
 :-o

I don't really know what to say in response. Do we congratulate them for acheiving this level of performance?

Or do we ridicule them severely for requiring such a hardware base to achieve it compared to the comparatively pathetic G3 Peg. Especially if we assume 64-bit recompiled version of the OS brushes aside all the previous x86 legacy excuses.

:-?

[Karlos]

bloodline wrote:
I've been reading Microsofts's Technical docs... apparently the x86's FPU (the x87) registers are not saved during a context switch in XP64... this means that you can't use the crappy x86 FPU anymore!!! It took 20 years, but finally they managed to get rid of that peice of junk :-D

You mean a task context switch? How frequent is that compared to the number of instructions executed between switches? I know the x86 FPU was a {bleep} to code for properly, but register save on context switch is not that big hit. On any x86 from the last 10 years the chances that the registers weren't just moved to/from L1 cache are almost nil.

So now, instead of backing up a handful of x86 FPU registers when a task switch occurs, you instead to back up the vector units register file? These units are far bigger than the old FPU register file - how does that make it faster?

This also means that the MMX and 3DNow! instruction sets no longer work.

In future all Floating point work is to be done by the Vector units, SSE and SSE2 :-)

This is good news all around!!! This also explains why we are seeing speed ups in 64bit version of windows when running 64bit apps.

Buh... surely FPU code designed for sequential execution is not going to run faster in the vector unit, just becasue it is a vector unit.

[Karlos]

bloodline wrote:

I though the usual approach was to walk into a shop and ask for one...

I tried that but they didn't have a clue what I was talking about.






Still, it was a greengrocers....

[Karlos]

That was clearly my mistake, then. I forgot I was in the UK :-(

Happens quite a lot these days. Must be that new Campbell's Soup I bought recently...

[Karlos]

The guy at my local cash'n'carry (great places for fresh fruit/veg/meat/anything you need for a good curry etc.) has the most delightful greeting.

It goes "Hello Please!"