Sign in with
Sign up | Sign in
Your question

athlon64 release speed

Tags:
Last response: in CPUs
Share
April 2, 2003 9:12:31 PM

athlonwill release higher than 2GHz and have pr rating between 3400 and 3600 :smile:
the guy i spoke to also was confident that it would be very competitive against prescott

I'm out of my mind, but feel free to leave a message.

More about : athlon64 release speed

April 3, 2003 12:06:50 AM

we shall see ;) 
April 3, 2003 12:34:23 AM

there 2 athlon 63 Paris and a opteron core with some ht link disable.So wich do you speak also even opteron got not much chance in single cpu again Prescott.Most of the hype they try to create is dead, most have loss faith in AMD.

[-peep-] french
Related resources
Can't find your answer ? Ask !
April 3, 2003 3:02:08 AM

Your right. I've lost faith with AMD. As for speed of Hammer I've seen 2.4 or 2.5 Gig Cpu. Prescott will be 3.4 with 800 FSB.
April 3, 2003 5:59:16 AM

If you had faith in a semiconductor corporation......you're desperately in need of a religion to mindlessly devote to....

"We are Microsoft, resistance is futile." - Bill Gates, 2015.
April 3, 2003 6:22:11 AM

Maybe reading their <A HREF="http://ww3.ics.adp.com/streetlink/amd" target="_new">Annual Report</A> will bring you back to the light or dark side depending on your bias or bios.

Dichromatic for your viewing plesure...
April 3, 2003 7:22:07 AM

im talking about the desktop athlon64 core. apparantly intel are having some trouble with motherboards and wont be going any higher than 3.6GHz this year at the most.. dont know what the problem is because i had to get to a presentation and didnt get to ask. anyway the athlon64 has 2ht links instead of 3 and is in single channel ddr. the opteron has 3ht links and dual channel.
also looks like they will only support ddr1 at release ddr2 will i assume come with updated core.
the os will actually be a update for windows server2003. the x86-64 extensions will just be bolted on the back end. interestingly enough the microsoft guy knew nothing about it when i asked him first and he suggested i talk to amd.. strange
it will be backwards compatable all the way back to 16bit natively. in fact they said they installed windows3.1 on an athlon64 system.. it took about 45seconds :lol:  they were using it to play pacman! and we can expect 15-20 % performance increase just going to 64bit os.. something to do with 64bit using the registers more efficiently

I'm out of my mind, but feel free to leave a message.
April 3, 2003 9:03:10 AM

One thing to note, AMD decided to drop pre-protected mode support (16-bit) when in 64-bit mode. That is, if you are running an OS that switches the processor to 64-bit mode, either compatibility or full 64-bit, you won't be able to run 16-bit applications natively. Although this really isn't an issue as Windows NT/2k/XP don't even run 16-bit applications natively anyway.

"We are Microsoft, resistance is futile." - Bill Gates, 2015.
April 3, 2003 9:44:55 AM

is any of this new news or am i a little behind and just finding out stuff you guys already know?

I'm out of my mind, but feel free to leave a message.
April 3, 2003 10:24:45 AM

I don't really care who launches what or at what speed as long as it's not a missile. Peace first, war later!

I am black, but i am not the devil --> >:) . !!!
April 3, 2003 10:42:39 AM

i agree with you but this is a cpu forum. not an anti-war political forum. if you must post about the war do t in the "other" forum.


I'm out of my mind, but feel free to leave a message.
April 3, 2003 5:04:24 PM

Quote:
and we can expect 15-20 % performance increase just going to 64bit os..

That's the part where you prove that you don't know what 64-bit in fact means. In the beginning most people thought that a 64-bit CPU offers twice the performance (read: speed) than a 32-bit CPU. In the meantime we all know that this is BS and that a 64-bit CPU only offers slight increases in performance in the range of 2-5%, if you can compare 64-bit programs with 32-bit ones at all!

You're 15-20% performance increase won't happen because
A) a program needs not only to be ported to 64-bit to make a speed increase noticeable but it also needs to be optimized for 64-bit which takes a very long time.

B) even if you succeed in optimizing a program/game for 64-bit, the code has changed that much that it is no longer comparable to the 32-bit counterpart (read: it evolved into different program)

If you really believe in this 15-20% speed increase, you will be severly disappointed! No doubt about it.

64-bit computing offers major advantages over 32-bit but none of them is currently available for the desktop user at home trying to play Unreal 2 or whatever game.

Don't expect doom3 to run 10-15% faster on a Athlon 64 than on a common 32-bit CPU, in fact don't even expect a 64-bit port of doom3 at all...
April 3, 2003 5:07:09 PM

Quote:
One thing to note, AMD decided to drop pre-protected mode support (16-bit) when in 64-bit mode. That is, if you are running an OS that switches the processor to 64-bit mode, either compatibility or full 64-bit, you won't be able to run 16-bit applications natively. Although this really isn't an issue as Windows NT/2k/XP don't even run 16-bit applications natively anyway.

Are you serious? That's kind of nuts. I mean that means that anyone with <i>any</i> old software will be pretty screwed to run it on an A64. Bummer. No Master of Magic! No Syndicate! :(  Naughty AMD. I'd expect that kind of nonsense from M$, but not from AMD.

<font color=blue><pre>If you don't give me accurate and complete system specs
then I can't give you an accurate and complete answer.</pre><p></font color=blue>
April 3, 2003 5:22:04 PM

So let me get this straight, if i want to use my current software i need to stick with a 32 bit cpu? If this is the case, i wont be needing a 64 bit cpu for several years :p 
April 3, 2003 5:33:08 PM

no, 32-bit programs will always run on the Athlon64, whether in 32-bit legacy mode or 32-bit compatiblity mode with 64-bit support.

Both previous posts were about older 16-bit programs...
April 3, 2003 5:36:37 PM

Quote:
no, 32-bit programs will always run on the Athlon64, whether in 32-bit legacy mode or 32-bit compatiblity mode with 64-bit support.

Both previous posts were about older 16-bit programs...

Exactly. And <i>I</i> happen to have plenty of old 16-bit programs that I still enjoy using.

<font color=blue><pre>If you don't give me accurate and complete system specs
then I can't give you an accurate and complete answer.</pre><p></font color=blue>
April 3, 2003 5:38:42 PM

but will current software perform better on these new cpus? or is it only 64 bit optimized software that will run better?
April 3, 2003 7:03:21 PM

yes, current 32-bit software will run faster on the Athlon64 but only because the Athlon64 is an improved 32-bit CPU (higher clockrate, more cache, improved branch predicitions and so on...) and not because it's an 64-bit CPU with a 64-bit OS. That's a big difference.

Don't mix up those two things!
April 3, 2003 7:45:30 PM

Ah finally im runnin in 64 bit mode lol :) 
April 3, 2003 7:56:38 PM

I believe you for now, though the news about it competing Prescott is a new one. Hopefully it's true, because Athlon 64 is delayed way outta its head, and the chances are slim if it don't perform at 2.5GHZ with at least a 20% IPC boost from a 2.5GHZ Athlon Barton.

--
This post is brought to you by Eden, on a Via Eden, in the garden of Eden. :smile:
April 3, 2003 8:14:10 PM

Dude, can't you read what RCJ even wrote just a LINE below his 64-bit statement?
The majority of this boost is probably due to the registers added, not because of 64-bit addressing. The guy did not make a misinformed statement at all, when he added such.

--
This post is brought to you by Eden, on a Via Eden, in the garden of Eden. :smile:
April 3, 2003 8:43:30 PM

Quote:
I believe you for now, though the news about it competing Prescott is a new one. Hopefully it's true, because Athlon 64 is delayed way outta its head, and the chances are slim if it don't perform at 2.5GHZ with at least a 20% IPC boost from a 2.5GHZ Athlon Barton.

Are you kidding? At this point all that AMD has to do is prove that the Athlon64 even works and the AMD pundits will proclaim it a great success. Besides, the more I think about it, chances are that all AMD will do is start releasing Bartons with a 400MHz FSB so that they can up the PR without having to actually nudge that GHz much (if any) higher. They'll probably proclaim a 400MHz FSB is worth 200 points over a 333MHz FSB and just up Barton's FSB to release a 3200+. It'll totally not be worth its price and everyone will be miffed.

And then the Athlon64 will come out and everyone will be happy just to have something with headroom to upgrade that isn't a flaming torch of a tiny CPU. It'll be the next best thing since sliced bread, even if the ratings that it's released at are the exact same as the AXPs (or less). They'll tout the ever-amazing 64-bit processing and memory controller built into the CPU as oh-so-spectacular, and in the end no one will care whether it's performace actually sucks for now. After all, the performance lag is all the OSs fault. Blame Microsoft, not AMD. Yeah. It'll get better ... right? No, seriously, it <i>will</i> get better, won't it? Not until 2H 04? Oh well...

Okay, so maybe that's a bit pessimistic. Maybe it really won't be that blindly stupid. Maybe AMD really will impress us. And then again, maybe not. There sure must be <i>some</i> reason (other than lame excuses) as to why it's taking this long to release the Athlon64...

Back a few I said that AMD must be having problems getting their new core to run on a .13 micron process. People said "Not a chance. AMD rocks. Look, they're finally releasing the Thoroughbred core. All is good. You're just nuts." And then we found out that the Thoroughbred core that they did release was pretty much at it's limit already and needed a core redesign to clock any higher with a decent yield.

Now AMD is delaying the Athlon64 like it the 'delay card' is the only one in their deck to deal. I propose that there's a <i>reason</i> for that, and it <i>isn't</i> the unavailability of a 64-bit OS.

Anywho, that's my dark thought for the day. :)  Enjoy.

<font color=blue><pre>If you don't give me accurate and complete system specs
then I can't give you an accurate and complete answer.</pre><p></font color=blue>
April 3, 2003 11:09:17 PM

Quote:
in fact don't even expect a 64-bit port of doom3 at all...

Why not? If ID soft can release Q3A for Linux, then it's very possible for them to make Doom3 for x86-64.

<b><A HREF="http://geocities.com/spitfire_x86" target="_new"> My Rig</A></b>
April 4, 2003 12:22:39 AM

oh, AMD's stock is up 10%. Still, it's half of what Intel is at, although both of them are nothing to write home about :) 

<font color=blue>Let's see, 500 posts a day, each day, for 30 days, and I will have more posts than Crashman!</font color=blue><P ID="edit"><FONT SIZE=-1><EM>Edited by hoserb2000 on 04/03/03 08:28 PM.</EM></FONT></P>
April 4, 2003 12:57:03 AM

LOL funny thread...

"i have lost faith in..."
Some people really need jesus in this thread :wink: or a girlfriend hehehe

<b>Damn War! I'm too young to watch other people die!</b>
<A HREF="http://members.iinet.net.au/~lhgpoobaa/images" target="_new">My Images!</A>
April 4, 2003 2:55:48 AM

Faith as in A company doing business not religion.
April 4, 2003 7:11:40 AM

Quote:
That's the part where you prove that you don't know what 64-bit in fact means. In the beginning most people thought that a 64-bit CPU offers twice the performance (read: speed) than a 32-bit CPU. In the meantime we all know that this is BS and that a 64-bit CPU only offers slight increases in performance in the range of 2-5%, if you can compare 64-bit programs with 32-bit ones at all!

im just telling you what the amd tech told me. like i said its something to do with 64bits using the rgisters more efficiently. didnt understand so im repeating parrot fashion as much as i can remember.
as for your statement that takes a long time to port and optimise a game etc that isnt entirelt true either apparently. unreal2 was ported in 2 hours.



what use is freedom of speech if the elected government refuses to hear?
April 4, 2003 7:29:54 AM

maybe i should have specified 15-20% in apps optimised for 64bit?
April 4, 2003 7:40:16 AM

He means in 64-bit mode. Which certainly could be true. Since in 64-bit mode, you get access to the extra registers in the processor vs 32-bit mode. That could potentially speed things up by 15-20%. This is, however, not a perk of "going 64-bit", it's merely something they've added to the x86-64 extension.

"We are Microsoft, resistance is futile." - Bill Gates, 2015.
April 4, 2003 8:05:13 AM

yes that pretty much sounds like what the guy was saying. sorry for the confusion
April 4, 2003 9:37:42 AM

Quote:
as for your statement that takes a long time to port and optimise a game etc that isnt entirelt true either apparently. unreal2 was ported in 2 hours.

There's a difference between porting and optimizing. Porting is done in several hours but surely won't deliever your 15-20% speed increase. Optimizing is a different story and takes much longer.

UT2003 has "only" been ported to 64-bit, but without much speed gain as Sweeney said himself.

Concerning Doom3, John Carmack already stated in some post that he won't do a 64-bit port of his upcoming game because it would take much time to port and optimized doom3 for 64-bit and the result would only be a minor speed gain.

I'm not saying that 64-bit games/programs won't be faster than 32-bit code if done correctly but people have to awake and stop believing in miracles which won't happen with 64-bit (such as tremendous speed increases out of nowhere)
April 4, 2003 11:49:39 AM

Nobody is, Christ, we're almost all knowing that the x86-64 porting uses as imgod2u specified, the extra registers, that's it, that's all.

--
This post is brought to you by Eden, on a Via Eden, in the garden of Eden. :smile:
April 4, 2003 11:56:35 AM

I for one will surely believe AMD will make a great product out of Opteron/Athlon 64, and that it's 32-bit performance will be very comparable to that of Prescott. Actually I believe Intels best move is to release their x86-64 CPU they've so secretly been working on ;) 
All my faith in AMD :p 

Besides I've heard that Hammer will finally introduce integrated thermal protection, another sign/hint of great quality.
April 4, 2003 2:07:29 PM

Quote:
There's a difference between porting and optimizing. Porting is done in several hours but surely won't deliever your 15-20% speed increase. Optimizing is a different story and takes much longer.

Porting entails optimizing, assuming you're using a high-level language (such as C/C++) and a decent compiler. Optimizing only really becomes a hassle if you drop into assembly language or the like, which hardly anyone does anymore.

Quote:
UT2003 has "only" been ported to 64-bit, but without much speed gain as Sweeney said himself.

I seem to remember something along the lines of 10-15% from porting/optimizing/whatever. Nothing earthshattering, but nothing to sneeze at either.

Quote:
I'm not saying that 64-bit games/programs won't be faster than 32-bit code if done correctly but people have to awake and stop believing in miracles which won't happen with 64-bit (such as tremendous speed increases out of nowhere)

Tremendous speed gains? Not really, we've been over this quite a lot. In the desktop space, most of the speed gains from Hammer porting/optimizing are going to come from the expanded register set, which is a big plus relative to traditional register-starved x86.

Any reasonably portable project is going to take advantage of the extra GPRs as soon as it gets recompiled with a Hammer-targeted compiler. I generally expect about 10% performance gains from this, give or take a few percent. But of course we won't know for a while yet.

<i>I can love my fellow man...but I'm damned if I'll love yours.</i>
April 6, 2003 9:12:29 PM

Porting entails optimizing, assuming you're using a high-level language (such as C/C++) and a decent compiler. Optimizing only really becomes a hassle if you drop into assembly language or the like, which hardly anyone does anymore.

Decent compiler that is missing as i know there only C++ compiler that not much

UT2003 really not a reference

i expect a decrease in perf when using 64 on game close to 50%

[-peep-] french
April 6, 2003 9:39:17 PM

Could you elaborate that last statement, which somewhat contradicts entirely what Sweeney has reported?

--
This post is brought to you by Eden, on a Via Eden, in the garden of Eden. :smile:
April 6, 2003 10:19:14 PM

Quote:
Decent compiler that is missing as i know there only C++ compiler that not much

C++ is generally enough for recent software.

The only widely-used languages that get compiled to machine-language anymore are C/C++, VBasic, and (occasionally) Java..

Most other languages (and even Java and VBasic, to some extent) are scripting languages that don't normally get compiled to anything machine-dependent. gcc already has a working x86-64 target for C/C++, and obviously, MS compilers have similar working targets (else they wouldn't even be able to develop Anvil).

C# might get compiled to ML, but C# hasn't really caught on yet. If/when it does, there will likely be an x86-64 target for it.

Quote:
UT2003 really not a reference

I'm interested in knowing the reasoning behind that. What's special about UT2K3 that makes it run better on x86-64, where everything else would supposedly run like crap?

Besides, it's a revision of a game engine that's already widely used in many other games. The UT2K3 engine will probably also be licensed for use in many games, so expect many of those other games to benefit from x86-64.

Quote:
i expect a decrease in perf when using 64 on game close to 50%

The expanded GPRs will benefit performance. And since the expanded GPRs can be used without turning on 64-bit addressing, I see no reason why porting would cause a performance decrease.

<i>I can love my fellow man...but I'm damned if I'll love yours.</i>
April 6, 2003 10:50:44 PM

Under spec benchmark show that inel compiler offer a 20 % increase in perf compare to the closest competitor.GCC is even slower.GCC the only compiler up to now for X86-64 ans is beta the support for vertor instrution will be hard to make.On game like bandwith matter a lot like Quake 3 64 bit will offer a decrease in perf if it get use.As you say the fastest config is 32 with Extra GPR so 64 is not faster as it make to run 32 code like any desktop PC.

Epic game is well now to be a bunch of PRO-AMD that give legacy code that run well on Athlon i dont expect 3dstudio max with massive optimization with intel compiler to swicth to a beta GCC that dont offer much.

how much Nvidia driver will work on a 64 bit windows and how much they are welling to support it as intel will still controle the market.

UT2003 switch legacy code for a others new X86 code so yes perf can be increase in case that it use 32 bit so bandwith can be save.On Quadro driver they allready have a low support of AMD compare to XEON i dont see a reason that will change in a near future as ZERO OEM back up Opteron up to now not IBM not HP not even Futjisu who just annouce Itanium base systemes for 2005 and XEON for 2003.Dell/IBM annouce I2 for 2003.Nec allready support I2 HP too SGI too.On workstation dell and HP and the main re seller and they use Intel xeon or high end P4 chip with RDRAM.

Support is very on OEM
Support is very low on driver
Support is very low on compiler

MS support with a real working compiler/OS may not come before 2004.ISV wont offer software or driver if they just got some linux support and a decrease in perf due to bad compiler or driver.Good compiler wont come if the market is .At best A64 will increase the number of systemes sold and there might be version of Divx for X86-64.In this case this wont come before Windows (anvil).


[-peep-] french
April 7, 2003 1:22:45 AM

Quote:
On game like bandwith matter a lot like Quake 3 64 bit will offer a decrease in perf if it get use.As you say the fastest config is 32 with Extra GPR so 64 is not faster as it make to run 32 code like any desktop PC.

Exactly. Porting to x86-64 doesn't require that you go full 64-bit. Most apps don't even need 64-bit addressing, so the developers just take what they want (expanded GPRs) and leave the rest.

Q3A, ported to x86-64 in the same manner as UT2K3, would probably get similar performance gains rather than the 50% performance loss you expect.

Quote:
I dont expect 3dstudio max with massive optimization with intel compiler to swicth to a beta GCC that dont offer much.

Why would they switch to GCC? AFAIK 3DSMax isn't getting coded for Linux anytime soon. There <i>is</i> incentive to port to x86-64, though, with 64-bit addressing and everything. Even light 3D rendering sucks up a great deal of RAM, and the cost of going with PAE is far greater than the cost of giving up vector opts.

Also, other compilers are catching up to Intel's compiler. gcc already generates faster code in some cases. The real reason icc gets so much attention is because it was the first to sport cutting-edge vector opts, which the P4 needs to perform decently.

Quote:
how much Nvidia driver will work on a 64 bit windows and how much they are welling to support it as intel will still controle the market.

nVidia is willing to support Linux very well, even though MS has far more monopoly power than Intel and far more marketshare than Linux. Plus, some nVidia drivers are already ported to x86-64.

Besides which, would nVidia really make an x86-64 chipset (Crush K8) without making x86-64-optimized drivers to support it? There's very little reason for them to give so much support to AMD and then stop halfway.

Quote:
On Quadro driver they allready have a low support of AMD compare to XEON i dont see a reason that will change in a near future as ZERO OEM back up

Any shortcomings in nVidia's x86-64 support <i>now</i> would have a lot to do with Hammer not actually being released yet. The current Athlon doesn't even really need or want any form of special attention on the Quadro's part.

Quote:
MS support with a real working compiler/OS may not come before 2004.

Anvil could easily come sooner than anyone expects. Hopefully we'll know more in two days.

<i>I can love my fellow man...but I'm damned if I'll love yours.</i>
April 7, 2003 4:04:04 AM

Exactly. Porting to x86-64 doesn't require that you go full 64-bit. Most apps don't even need 64-bit addressing, so the developers just take what they want (expanded GPRs) and leave the rest.

Even you have to built 2 library 1 for A64 1 for IA-32 i dont think so or you sell 2 difference version or offer patch on the net.Bolt are not really good choice.


Why would they switch to GCC? AFAIK 3DSMax isn't getting coded for Linux anytime soon. There is incentive to port to x86-64, though, with 64-bit addressing and everything. Even light 3D rendering sucks up a great deal of RAM, and the cost of going with PAE is far greater than the cost of giving up vector opts.

Also, other compilers are catching up to Intel's compiler. gcc already generates faster code in some cases. The real reason icc gets so much attention is because it was the first to sport cutting-edge vector opts, which the P4 needs to perform decently

$ GB of ram it hit only on few market that run on RSIC base i dont get why they will flush there RISC base for a slow not proven base.Pixar can be a case they have buy a 1000 XEON 2.8 GHZ machine.

If ISV dont port to linux they will have to wait for MS.

Intel compiler is still well ahead they new open MP will help on Multi tread code manly reduce cost of porting this feature is support only be IA-64 IA-32.Once again the lack of own software from AMD is lacking.Still waiting for MS


Nividia driver they offer Ia-64 driver for a long time if they split they resource bettween IA-32 and X86-64 ATI may get the advantage on mainstream market and unlike the CPU market that where is the money.SO they can allocate some resourece but very limited until they got a number of apps that run and need 64 bit and with a good number of apps sold.



Anvil release date i think 2003 advanced sver is release and offer support for IA-64 and IA-32 nothing mention yet X86-64 so only a long beta test on a wide number of machine for test and debuggie process and optimization across the platform wich.i think .Net been in beta test for 2 year on a very large number of machine from Intel wich AMD cannot even produce also how much AMD can help them they have to deal to convince a bunch of OEM and bebugge they own Driver and bios.

The same have happen on IA-64 in the 1 month bug where found in the bios slow driver and weak compiler.

I2 produce 600 int Spec HP compiler produce 800 intel next update will come soon and there much more room of improvement on I2 that opteron.Consider the resource that intel have put to create and test E8700 and driver for multiple OS and others.Work with OEM priority systemes and own OS software.Offer a wide range of machine from high Power Madison to low power deerfield.Also the controle on Red hat.


A64 VS P4 do you really think they got a chance.
Opteron Vs Risc base and I2 no
Opteron vs Xeon DP MP yes that what they aim and that what they can gain some market share without offer at 1/2 price.

Due to high branch workload where P4 dont shine.Low-end web server to mid web sever.

[-peep-] french
April 7, 2003 4:40:30 AM

Quote:
Even you have to built 2 library 1 for A64 1 for IA-32 i dont think so or you sell 2 difference version or offer patch on the net.Bolt are not really good choice.

Why not? It's been done many times before, with both 3DNow! and SSE/SSE2. It can be done with a feature check at run-time.

Quote:
$ GB of ram it hit only on few market that run on RSIC base

3D rendering is one of those markets. Just a few reasonably realistic objects can drive memory usage up to half a GB. Craft an entire outdoor scene with full props, and mem usage skyrockets...

Quote:
Intel compiler is still well ahead they new open MP will help on Multi tread code manly reduce cost of porting this feature

<A HREF="http://www.coyotegulch.com/reviews/intel_comp/intel_gcc..." target="_new">Only if you're using a Pentium4.</A> For other processors, gcc tends to match and sometimes exceed what icc can do.

Quote:
Nividia driver they offer Ia-64 driver for a long time if they split they resource bettween IA-32 and X86-64 ATI may get the advantage

That explains why they're alread posting x86-64 drivers... :wink:

Quote:
A64 VS P4 do you really think they got a chance.

If Athlon64 meets its release target, Intel's going to either have to push harder or get stuck in second place again.

<i>I can love my fellow man...but I'm damned if I'll love yours.</i>
April 7, 2003 9:25:43 AM

Quote:
Only if you're using a Pentium4. For other processors, gcc tends to match and sometimes exceed what icc can do.


Actually, I don't think this is true at all. As I recall, even the Athlon received a sizable benefit from compiling their SpecInt and SpecFP benchmarks using Intel's compiler vs GCC. Generally speaking. GCC isn't a very good compiler from a performance point of view. Many other compilers out there are more specialized (Microsoft's for example, although not quite as much). Intel's, I would say, would be the best compilers for the x86 platform. And rightly so, it was developed for the sole reason of improving x86 performance.

As for x86-64. While you won't have to use 64-bit integers (which can take up space), you do have to use 64-bit pointers. Whenever you're in 64-bit mode (whether compatibility or full), your pointers are 64-bits. If you're in legacy mode, you don't get to use the extra registers. And I can tell you right now that in games like Q3A, pointers are used a lot more than integers. And doubling the space that pointer takes up would take up significantly more cache. Let's hope the added registers can offset this effect.

"We are Microsoft, resistance is futile." - Bill Gates, 2015.
April 7, 2003 9:52:36 AM

Quote:
Actually, I don't think this is true at all. As I recall, even the Athlon received a sizable benefit from compiling their SpecInt and SpecFP benchmarks using Intel's compiler vs GCC.

That was true for gcc-2.x, and for early gcc-3.x releases. There's been some changes though, and the linked benchmarks bear that out. icc far outpaces gcc for Pentium4-optimized code, but the two are apparently a wash for Pentium3-optimized code.

Even more big changes are going into the branch destined to become gcc-3.4. Basically the compiler guts are getting rearranged so that platform-specific opts (specifically vector opts) become easier to implement.

Quote:
As for x86-64. While you won't have to use 64-bit integers (which can take up space), you do have to use 64-bit pointers. Whenever you're in 64-bit mode (whether compatibility or full), your pointers are 64-bits. If you're in legacy mode, you don't get to use the extra registers.

Actually, when in 64-bit mode, you can use the expanded GPRs without using 64-bit addressing. From the <A HREF="http://www.amd.com/us-en/assets/content_type/white_pape..." target="_new">AMD x86-64 architecture manual</A>, page 6:

Quote:

The address-size override prefix (67h) selects the non-default address size. Depending on the operating mode, this prefix allows mixing of 16-bit and 32-bit, or 32-bit and 64-bit addresses, on an instruction-by-instruction basis.

<i>I can love my fellow man...but I'm damned if I'll love yours.</i>
April 7, 2003 12:13:49 PM

Why not? It's been done many times before, with both 3DNow! and SSE/SSE2. It can be done with a feature check at run-time.


Long live code bloat it a full retructure of register and load store the code will get much bigger.Bad of perf higher memory usage higher storage use bad when you pay few 1000$ for 15KRPM scsi or solid state disk.


3D rendering is one of those markets. Just a few reasonably realistic objects can drive memory usage up to half a GB. Craft an entire outdoor scene with full props, and mem usage skyrockets...

Does who run over 4GB of ram allready have 64 bit RISC base.Still 4 GB ram or more is lesss that 0.1 % of the market

For other processors, gcc tends to match and sometimes exceed what icc can do

Opteron spec int and FPU wa running on intel compiler 5.01 that use better vertor ops code and better ILP.

Also intel compiler suppport all IA-64 base.

That explains why they're alread posting x86-64 drivers...

Via make driver too dont mean they are good.

If Athlon64 meets its release target, Intel's going to either have to push harder or get stuck in second place again.

That very faithful vs a presscott with close to 2X the clock speed.A64 use a opteron core by now with 1MB of cache high cost production low clock speed

[-peep-] french
April 7, 2003 4:31:49 PM

Quote:
That was true for gcc-2.x, and for early gcc-3.x releases. There's been some changes though, and the linked benchmarks bear that out. icc far outpaces gcc for Pentium4-optimized code, but the two are apparently a wash for Pentium3-optimized code.

Even more big changes are going into the branch destined to become gcc-3.4. Basically the compiler guts are getting rearranged so that platform-specific opts (specifically vector opts) become easier to implement.


This may well be true. But keep in mind that Intel's compilers are improving as well. The latest 7.0 version brought about quite a bit of improvement. I don't think it was just for the P7 core either.

Quote:
Actually, when in 64-bit mode, you can use the expanded GPRs without using 64-bit addressing. From the AMD x86-64 architecture manual, page 6


That's very interesting. Mix and match pointers. I could see that being a potential nightmare, especially when you take into account arrays and other pointer-size-dependent structures.
Also, doesn't this mean that a lot of programs will have literally millions, if not billions of extra x86 tags? Oh yippie, more complex instructions, and by the tons.

"We are Microsoft, resistance is futile." - Bill Gates, 2015.
April 7, 2003 7:11:22 PM

Quote:
Also, doesn't this mean that a lot of programs will have literally millions, if not billions of extra x86 tags? Oh yippie, more complex instructions, and by the tons.

Actually, many programs might forego the prefix and use RIP-relative addressing instead, where address operands are 32-bit signed offsets off the RIP register. Probably gets the same benefit (reduced pointer size), although I can't be certain. Now <i>that</i> could be hairy, at least for the compiler to manage. :wink:

<i>I can love my fellow man...but I'm damned if I'll love yours.</i>
April 8, 2003 7:54:33 AM

Quote:
Actually, when in 64-bit mode, you can use the expanded GPRs without using 64-bit addressing. From <A HREF="http://www.amd.com/us-en/assets/content_type/white_pape..." target="_new">the AMD x86-64 architecture manual</A>, page 6:

and

Quote:
The expanded GPRs will benefit performance. And since the expanded GPRs can be used without turning on 64-bit addressing, I see no reason why porting would cause a performance decrease.

I'm not sure what you mean by turning on 64-bit addressing.

I've been studying x86-64 and in 64-bit mode you are always using 64-bit addressing. You can only use the expanded GPRs (R8-R15 and the XXM8-XXM15) in 64-bit long mode. This however, does not mean you need to store pointers and data as 64-bits. The exception to this is the stack. Stack frames will maintain 64-bit addressing when ENTER/LEAVE commands are used. When in 64-bit mode 32-bit data is automatically promoted in register to 64-bit data. If you move a number into EAX or it is automatically promoted by bit extension to RAX size. The extended registers are not explicitly maintained when the processor changes to compatibility mode or legacy mode.

Dichromatic for your viewing plesure...
!