athlon 64: why is it's poor multitasking ignored/downplayed?

[Algere]

Originally posted by: Lithan
A64 is a 32bit processor with 64bit extensions. There are a few proprietary processor manufacturers that make fully 64bit cpus. And they, mhz for mhz, absolutely stomp all over the A64. And surely whatever 32bit processors Intel decides to enable 64bit on.

Other way around, A64 is a 64 bit processor with 32 bit compatibility and AFAIK those processors don't run on x86 (maybe transmeta don't remember).

 

[Lithan]

The 64-bit capabilities of the Athlon 64 are merely extensions to the existing x86 instruction set. The Athlon 64 supports, 100% natively, all existing x86 code. The addition of x86-64 extensions is the same thing as the addition of MMX or SSE?it is simply a new feature that will probably provide some performance benefits as soon as software is written to take advantage of it.

 

[Algere]

Link?

EDIT: Here's my link

"On the applications side, since the Athlon64 is completely backward compatible, you should have no problems running any 32-bit applications on a 32-bit Operating System"

 

[jhu]

Originally posted by: Lithan

The 64-bit capabilities of the Athlon 64 are merely extensions to the existing x86 instruction set. The Athlon 64 supports, 100% natively, all existing x86 code. The addition of x86-64 extensions is the same thing as the addition of MMX or SSE?it is simply a new feature that will probably provide some performance benefits as soon as software is written to take advantage of it.

well, yes, that would definitely make it a 64-bit processor. the addition of mmx or sse is different because no new addressing modes are introduced with those instruction sets. it's like saying the 386, 486, pentium, pentium2/3/4 aren't 32-bit processors, but rather they're all 8-bit processors with 16-bit and 32-bit extensions.

 

[Viditor]

CaiNaM - Please post back as soon as you've tried it...very interesting scenario!

Vee - GREAT post and very informative...thanks!

Algere - let it lay...he believes what he believes, and no amount of definitions and proof will change that.

 

[Algere]

No matter I googled where he/her found it, found his/her link so to speak or a copy of the text

Silent PC Review

As to the validity of the statement...

P.S. Then again I guess it could just depend on what extensions mean, either an additition/modification to the existing x86 code and/or the addition of instruction sets.

I tend to stick with the latter

 

[Lithan]

Originally posted by: jhuwell, yes, that would definitely make it a 64-bit processor. the addition of mmx or sse is different because no new addressing modes are introduced with those instruction sets. it's like saying the 386, 486, pentium, pentium2/3/4 aren't 32-bit processors, but rather they're all 8-bit processors with 16-bit and 32-bit extensions.

What you fail to realize is that what you just said is completely true.

I'd expect that when 64bit becomes something serious for the home user, Amd will dump the tired x86 architecture and build a real 64bit cpu.

 

[jhu]

Originally posted by: Lithan

Originally posted by: jhuwell, yes, that would definitely make it a 64-bit processor. the addition of mmx or sse is different because no new addressing modes are introduced with those instruction sets. it's like saying the 386, 486, pentium, pentium2/3/4 aren't 32-bit processors, but rather they're all 8-bit processors with 16-bit and 32-bit extensions.

What you fail to realize is that what you just said is completely true.

I'd expect that when 64bit becomes something serious for the home user, Amd will dump the tired x86 architecture and build a real 64bit cpu.

that's not quite true. the pentium 2/3/4 doesn't execute the instructions directly. architectureally they're original designs. when 64-bit home computing becomes more mainstream, the x86 instruction set will not be going away since that's what the majority of programs will be using. see itanium, alpha, etc.,

 

[Lithan]

You can support x86 without building around it. It simply wont be as efficient. But which is more important? Performance for current apps or for older apps? I vote for current apps. Hell, if the performance difference was significant enough, I'd conceed all support for any software made before so and so time. I'd keep a legacy system around to run that software if I needed it.

 

[jhu]

Originally posted by: Lithan
You can support x86 without building around it. It simply wont be as efficient. But which is more important? Performance for current apps or for older apps? I vote for current apps. Hell, if the performance difference was significant enough, I'd conceed all support for any software made before so and so time. I'd keep a legacy system around to run that software if I needed it.

you have a mac?

 

[Lithan]

Heh, macs don't get to be called computers. They are neon toasters with internet access.

 

[CaiNaM]

ok, some interesting stuff...

intel p4 HT enabled
--------------- CPU ---------- MEM -----
game.dll ---- 50 ---------- 305,736k
game.dll ---- 50 ---------- 332.723k

intel P4 HT disabled
--------------- CPU ---------- MEM -----
game.dll ----- 20 - 35 ---- 174,120k
game.dll ----- 65 - 80 ---- 402,696k

a64
--------------- CPU ---------- MEM -----
game.dll ----- 50 - 100 --- 305,736k
game.dll ----- 00 - 50 ----- 332.723k

you can also set client "sleep" mode, where the client sleeps when in the backgroud or minimized. i wasn't was going back as i didn't get to ck how it "felt" when playing with HT disabled on the P4 (sleep mode didn't help the a64 at all), and to verify the client mode on that pc, but when i went back to disable HT in the bios for the second time, my pc wouldn't boot (won't even POST). seems a mb issue.. ugh.. so while we have some info for further speculation, for now, this is all the update I have... of to the hardware store to see if they have an 865 board....

 

[Viditor]

But which is more important? Performance for current apps or for older apps?

Actually, you've phrased that incorrectly. It should read support for current apps or support for future apps, and Itanium answered that question for us. Apparently it's support for current apps as demonstrated by Itanium's dismal sales, even after 3 1/2 years...

 

[Algere]

Originally posted by: CaiNaM
ok, some interesting stuff...

intel p4 HT enabled
--------------- CPU ---------- MEM -----
game.dll ---- 50 ---------- 305,736k
game.dll ---- 50 ---------- 332.723k

intel P4 HT disabled
--------------- CPU ---------- MEM -----
game.dll ----- 20 - 35 ---- 174,120k
game.dll ----- 65 - 80 ---- 402,696k

a64
--------------- CPU ---------- MEM -----
game.dll ----- 50 - 100 --- 305,736k
game.dll ----- 00 - 50 ----- 332.723k

you can also set client "sleep" mode, where the client sleeps when in the backgroud or minimized. i wasn't was going back as i didn't get to ck how it "felt" when playing with HT disabled on the P4 (sleep mode didn't help the a64 at all), and to verify the client mode on that pc, but when i went back to disable HT in the bios for the second time, my pc wouldn't boot (won't even POST). seems a mb issue.. ugh.. so while we have some info for further speculation, for now, this is all the update I have... of to the hardware store to see if they have an 865 board....

FYI: There's a big ongoing thread over @ Futuremark about the same thing. They might've done some A64 vs. P4 HT enabled/disabled testing.

 

[Viditor]

CaiNaM - Interesting...from your notes, I don't see why the A64 is performing so dismally.

Could you try analysing the thread count as well?

Thread Count Analysis Page from Microsoft

 

[Lithan]

Originally posted by: Viditor

But which is more important? Performance for current apps or for older apps?

Actually, you've phrased that incorrectly. It should read support for current apps or support for future apps, and Itanium answered that question for us. Apparently it's support for current apps as demonstrated by Itanium's dismal sales, even after 3 1/2 years...

No I didn't phrase it incorrectly. I said that AMD made the right choice for short term performance. But is putting future performance on the back burner. Which will cost them when the 64 bit shift comes in full.

 

[Viditor]

Another interesting tidbit I found in that thread you linked cainam...

"I don't know what Microsoft has done to screw up the multi-tasking on Athlons so badly.

Here at work we run Linux on our server boxes. On the AMD systems we are capable of loading the PCI busses to the max (and I mean maxed out) driving 2 x GigE cards as fast as PCI will go. Then we have 12 x 10K RPM SCSI drives going flat out. The boxes are serving around 5000 simultaneous transactions at a rate of 2000 transactions per second, multiplexed across about a dozen worker threads, and the user level responsiveness is just fine.

Then I come here and read about how on Windows that a few text-based IRC jobs are going slow whenever someone listens to some music, and I'm suddenly thinking, WTF?"

This makes it sound as if it's a Windows scheduler issue...correctable?

 

[Viditor]

I said that AMD made the right choice for short term performance. But is putting future performance on the back burner. Which will cost them when the 64 bit shift comes in full

I'm not sure I understand what you envision as a "true 64-bit" architecture, but as many (if not most) businesses are gearing up for x86-64 (doesn't matter if it's AMD64 or EMT64), I don't see any other architecture replacing it for quite some time.
The biggest lesson learned from Itanium is that (because of economics) any shift to a new architecture MUST be evolutionary and not revolutionary. By that I mean it must run all existing apps at least as fast and efficiently as is currently available. Itanium was and is x86 compatable, it's just not very good at it...

 

[Lithan]

Originally posted by: Viditor
Another interesting tidbit I found in that thread you linked cainam...

"I don't know what Microsoft has done to screw up the multi-tasking on Athlons so badly.

Here at work we run Linux on our server boxes. On the AMD systems we are capable of loading the PCI busses to the max (and I mean maxed out) driving 2 x GigE cards as fast as PCI will go. Then we have 12 x 10K RPM SCSI drives going flat out. The boxes are serving around 5000 simultaneous transactions at a rate of 2000 transactions per second, multiplexed across about a dozen worker threads, and the user level responsiveness is just fine.

Then I come here and read about how on Windows that a few text-based IRC jobs are going slow whenever someone listens to some music, and I'm suddenly thinking, WTF?"

This makes it sound as if it's a Windows scheduler issue...correctable?

I've been making that arguement for months. But noone wants to listen.


What Itanium taught us is... Don't charge a premium for something which someone else can do better.

 

[Vee]

Originally posted by: CaiNaM
intel P4 HT disabled
--------------- CPU ---------- MEM -----
game.dll ----- 20 - 35 ---- 174,120k
game.dll ----- 65 - 80 ---- 402,696k

a64
--------------- CPU ---------- MEM -----
game.dll ----- 50 - 100 --- 305,736k
game.dll ----- 00 - 50 ----- 332.723k

My immediate reaction to this is that it ought to be some kind of configuration issue.
That is: Multitasking should be entirely in the hands of Windows, so it's hard to envision something else causing this.

Edit: What is the basic priority of their processes?
(Taskmanager-Processes-show base priority) By right clicking on a process, you can lower it's priority, which can be useful if a task that should be 'background' annoy you by hugging too much cpu.

Also I think: This computer-properties-advanced-performance-advanced -> check for optimizing for program should be best choice.

 

[CaiNaM]

Originally posted by: Vee

Originally posted by: CaiNaM
intel P4 HT disabled
--------------- CPU ---------- MEM -----
game.dll ----- 20 - 35 ---- 174,120k
game.dll ----- 65 - 80 ---- 402,696k

a64
--------------- CPU ---------- MEM -----
game.dll ----- 50 - 100 --- 305,736k
game.dll ----- 00 - 50 ----- 332.723k

My immediate reaction to this is that it ought to be some kind of configuration issue.
That is: Multitasking should be entirely in the hands of Windows, so it's hard to envision something else causing this.

well, that's the problem.. threading processing on the a64 appears to be done entirely by windows (software), on intel architecture HT allows for simultaneously running multiple proccesses in parellel on one cpu. the theory i'm we seem to be following at this point (and while not proven, certainly makes some sense) is that controlling these processes from hardware (cpu) rather than software (windows) is more efficient, explaining the problem with running more than 1 cpu intensive app..

 

[Vee]

Originally posted by: CaiNaM
... is that controlling these processes from hardware (cpu) rather than software (windows) is more efficient, explaining the problem with running more than 1 cpu intensive app..

Not really. Multitasking must be controlled by OS, and is so for HT P4s too. The difference is that the sheduler releases two threads (if there is a second thread that is not blocked).

HT allows slightly more total work to be got out of a P4, but it is not more efficent, because every thread still has to go by Windows sheduler, don't imagine anything else.
What can make HT more efficient, is if some thread is waiting actively, keeping a high priority.

As for that and multitasking disturbing the work or affecting the PCs behavior, that's just Windows, combined with Windows apps that aren't as good as they could be, I'm afraid.

 

[Viditor]

controlling these processes from hardware (cpu) rather than software (windows) is more efficient, explaining the problem with running more than 1 cpu intensive app..

I don't know if that's true (it might be, I just don't know). The post from the guy running Linux indicates that it's not...the problem appears to be in Windows itself (of course that's bad for AMD...).

 

[CaiNaM]

Originally posted by: Viditor
CaiNaM - Interesting...from your notes, I don't see why the A64 is performing so dismally.

Could you try analysing the thread count as well?

Thread Count Analysis Page from Microsoft

well, both clients run 8 threads.. on either machine, and does not deviate from that...

 

[CaiNaM]

Originally posted by: AlgereFYI: There's a big ongoing thread over @ Futuremark about the same thing. They might've done some A64 vs. P4 HT enabled/disabled testing.

heh.. i read thru about 10 pages in that thread, and only saw like 3 intelligent posts.. the majority of them are all flag waving idiots defending their chosen cpu brand.. the discussions tend to be much more intelligent here