Sign in with
Sign up | Sign in
Your question

Athlon64 vs Prescott

Tags:
Last response: in CPUs
Share
April 9, 2003 3:27:39 AM

Athlon64 to launch same time as Prescott. A64 will use 130nm Prescott will use 90nm. So in six months when AMD A64 goes to 90nm what will Prescott be doing?

More about : athlon64 prescott

April 9, 2003 3:33:20 AM

Drinking a beer?

Think that intel wont feel the pressure to go smaller until they reach a limit. Why rush when there is no need?

<font color=red>*</font color=red><font color=white>*</font color=white><font color=blue>*</font color=blue>
... And I'm proud to be an American, where at least I know I'm free, and I won't forget the men who died, who gave that right to me.
April 9, 2003 4:24:19 AM

Prescott: "Nah nah nah nah nah nah, I use a more advanced process technology"
Athlon64: "I know you are but what am I?"
Prescott: "130 nm, old technology"
Athlon64: "Damn!!!"

6 months later...

Athlon64: "Ha! I'm on 90 nm too!"
Prescott: "So what are you up to now? 2.2 GHz?"
Athlon64: "Bah! My clockspeed is worth more!"
Prescott: "Whatever, I still have more."
Athlon64: "You suck! I'm more efficient!"
Prescott: "How? You use as much power as I do for the same performance."
Athlon64: "But but but........I have less MHz."
Prescott: "I thought you said MHz wasn't important."
Athlon64: "AMD RULEZ 0WNS YOU!! I'M L33T!"

to be continued......

Ok, so the processors themselves won't be saying that, but you can damn well be sure all the fanboys will be.

"We are Microsoft, resistance is futile." - Bill Gates, 2015.
Related resources
April 9, 2003 9:56:40 AM

You know ... Though I always have slightly favoured Intel, I think it's a pitty how people are killing the Athlon64 even before it has come out. I still think it will be an impressive piece of hardware. In 'standard' 32-bit mode it will be more effecient than current Athlons, due to the redesign of the internal core, and also due to the integration of the memory-controller on-chip. And don't forget that it will (at last) incorporate SSE2. When running on the appropriate OS, with 64-bit-mode enabled, and running the right software to take advantage of it, the added registers and the raw 64-bit calculating power will make this one hell of a mean lean computing machine ... (though actually every MMX-enabled CPU is already capable of 64-bit arithmetics ...).
Anyway, I really don't like the way people are preliminarly destroying this potentially very cool CPU.

Greetz,
Bikeman

<i>Then again, that's just my opinion</i>
April 9, 2003 10:14:53 AM

Quote:
Athlon64 to launch same time as Prescott. A64 will use 130nm Prescott will use 90nm. So in six months when AMD A64 goes to 90nm what will Prescott be doing?

Don't bet on it that AMD will be ready for 0.09micron six months after the launch of their Athlon64. They had too much delays for me to believe that they will manage the die shrink that fast...

Concerning the performance of a Athlon64 compared to Prescott (32-bit operations) it's still impossible to tell anything because there's is almost no information available on the Prescott (besides a few technical details)...
April 9, 2003 12:29:20 PM

Has everyone forgot that half the technology push for AMD has been SOI?

Didn't they sell their soul for the golden substrate?

Not that IBM is evil or anything.

Dichromatic for your viewing plesure...
April 9, 2003 1:42:28 PM

Your conversation there was quite amusing... :smile:

You know, it´s very likely that that´s really going to happen, which only makes it funnier...
April 9, 2003 1:56:17 PM

Heh heh. Sadly imgod2u, that's likely to be a real conversation in a few months. I'm not sure in it being likely makes it more or less funny... I mean it is damn funny, but it's also so sad...

<font color=blue><pre>I'm proud to be an American,
who served my country in the US Air Force,
to protect the rights of my fellow Americans,
to hold protests against others like me.</pre><p></font color=blue>
April 9, 2003 2:00:12 PM

Quote:
Anyway, I really don't like the way people are preliminarly destroying this potentially very cool CPU.

bikeman, I think you're being a tad over-sensitive. The only people 'destroying' the Athlon64 are the folks at AMD who are taking so long to release it. It is (and maybe still does) indeed have the potential to be a 'very cool CPU'. However that potential spins further and further down the toilet with each delay from AMD. Potential energy only becomes kinetic energy if it finally <i>does something</i>.

<font color=blue><pre>I'm proud to be an American,
who served my country in the US Air Force,
to protect the rights of my fellow Americans,
to hold protests against others like me.</pre><p></font color=blue>
April 9, 2003 2:11:54 PM

I thought it's already happened in this thread, see above for detail :) 

You never know how stupid you are until you have done something stupid enough for you to realize it.
<A HREF="http://www.anandtech.com/mysystemrig.html?id=22996" target="_new">My System Rig</A>
April 9, 2003 2:45:29 PM

Quote:
Heh heh. Sadly imgod2u, that's likely to be a real conversation in a few months. I'm not sure in it being likely makes it more or less funny... I mean it is damn funny, but it's also so sad...


I pride myself on deep and insightful humor.

"We are Microsoft, resistance is futile." - Bill Gates, 2015.
April 9, 2003 5:30:53 PM

Yes, Slvr, you are right. This thing should've been out for already a long time. But it remains a fact that it's potential still is huge. And I'm actually not defending AMD, I am just pitying the fact that a piece of technology that a few months ago (before I temporarily left these fora) was still respected and people were waiting for with big expectations, now is regarded inferior to a new chipset coming out for an already existing processor (ok, opening big perspectives).
Concerning Prescott, by the way, I think of that as a more 'natural' evolution of the current P4's. Eliminating some of it's bottlenecks, improving it's scalability and implementing a few new features. It will be a nice step forward, I think, without any doubt. But I think it will be necesary for Intel to remain competetive, as I still see a true thread in the A64 for it
Hmm, yes, maybe it will be like this: with a more revolutionary A64 AMD might close in on Intel's more naturally evolved Prescott, in the end getting to equal levels, once again ...

And now, time for dinner.

Greetings,
Bikeman

<i>Then again, that's just my opinion</i>
April 9, 2003 5:45:57 PM

If and when Athlon 64 launches, and if software makers implement 64-bit software like crazy, Intels best move would probably be to release Yamhill, their x86-64 CPU.
April 9, 2003 9:04:11 PM

Quote:
If and when Athlon 64 launches, and if software makers implement 64-bit software like crazy, ...

Then Intel 's got a problem. I once, a few months ago, pointed out already, that it is very unlikely for Intel to bring out an x86-64 compatible CPU ... Can you imagine? Intel actually paying AMD for licensing? I don't, actually.
So there are two possibilities, from my point of view at least: One: Intel will introduce it's proprietary x86-64-like code, and we'll be living in a 64-bit computing hell, or ... Two: Yamnill wil be an IA-64 derivate, for which nowadays many products are available (Even windows XP for IA-64, and nVidia drivers) and Intel will try to eradicate any x86-64 resistance it meets on it's path.
No, those points of view aren't exactly correct, but anyway, you probably see that yamnill poses a though question for the industry, about bringing 64)bit computing to the desktop.

Greetz,
Bikeman

<i>Then again, that's just my opinion</i>
April 9, 2003 9:27:13 PM

I still believe that if AMD makes a very profitable products out of Hammer, and if software makers start making 64 bit programs, or even programs supporting both 32 and 64 bit code, then my guess is that Intel will follow suit and finally introduce Yamhill.

I didn't know that a point of view could be wrong? :p 
No offense taken, it's just what I believe. I agree with you though about what Intel would do if they ever introduce Yamhill. Like you say, it's *extremely* unlikely that they would ever purchase a licence from AMD. I'd say they create their own x86-64 code to make their own CPU that handles both 32 and 64 bit programs.
April 9, 2003 10:26:58 PM

Why do you believe that the Yamhill is a Athlon 64 clone and not something completely different? Does it even really exist? Yamhill remains a complete mystery...

Another mystery which is still not solved is if any average user (the same user which owns currently a Athlon XP or a Pentium 4 ) really needs a 64-bit CPU before, let's say 2007. I'm pretty sure average Joe doesn't need one. Why should he?

Doing the transition from 32-bit to 64-bit is a complete different thing. In that way the Athlon 64 is a great CPU but I don't believe it will work out like AMD hopes it will happen. The average user isn't ready for 64-bit, in any way, he doesn't need really a 64-bit CPU.

Most people have 256 to 512 mb of RAM. Hardcore user may have 1gb to maybe 2gb of RAM. The limit of 4gb won't be broken and needed before 2005.

The same for 64-bit operations, no program really needs 64-bit extensions and if it does, you're really better off with the Itanium, that means if you really need a program to do 64-bit operations, it's for something really important and you certainly have the money for a Itanium and not for a cheap first generation Opteron.

There's only one hope that the Hammer CPU will succeed for the time being, that is, that it will be a performant 32-bit CPU. The rest is a gimmick. Games and programs run fine with 32-bit and probably are better off with Prescott CPU with enhanced Hyperthreading, optimized pipeline, better branch prediction, increased FSB, higher clockrate and higher IPC.
April 9, 2003 10:41:00 PM

While I should be the first to admit I do not know a whole lot about the benefits of 64-bit code vs. 32-bit, I still don't understand why anyone should want to wait for new technology if it can already be had. Is it the price? If not, I really can't see why we wouldn't need it. Please, educate me, because like I said, I really don't know much about the difference between 64-bit code vs. 32-bit code.

I can't agree with you on your last sentence. Naturally, as I see it, a CPU handling both 32-bit and 64-bit code would be a whole lot more universal than a CPU only handling 64-bit code would. But that's just how I see it.

Prescott seems strong. Athlon 64 seems too. It will be nigh on impossible to assume what's gonna be best for 32-bit usage by then. Prescott is also somewhat of a mystery, in that we don't know all the details about it. Except it's added registers, and 1 mb cache.
<P ID="edit"><FONT SIZE=-1><EM>Edited by sabbath1 on 04/09/03 06:59 PM.</EM></FONT></P>
April 9, 2003 11:07:34 PM

Quote:
I can't agree with you on your last sentence. Naturally, as I see it, a CPU handling both 32-bit and 64-bit code would be a whole lot universal than a CPU only handling 64-bit code. But that's just how I see it.

The reason for this is that a real 64-bit CPU can do 64-bit work much better than 32-bit/64-bit hybrid because it's only purpose is 64-bit and not some mélange of different CPU generations trying to do the best of two different worlds!

To answer your first question is more difficult since 64-bit CPU are not just the double "whatever" of a 32-bit CPU. A 64-bit Intel Itanium is something completely different than a 64-bit AMD Hammer CPU. Both can execute 64-bit instructions per clockcycle but both 64-bit instructions are completely different and not compatible. So to say, they can do both do "double" the work in the same time than a 32-bit CPU but it's always a different work. In real performance terms the benefit is only something fraction of the 200% and only this if it's a real 64-bit CPU with real 64-bit optimizations not some random port like it's happening now with UT2003. It's just marketing: Buy our 64-bit UT2003 because is much better than the standard UT2003! yeah whatever, the graphics are the same, the gameplay is the same and it runs only a few percents faster than the 32-bit version but it's "64-bit". Big improvement!

To explain you the advantages of a 64-bit only CPU and a 32-bit/64-bit mélange is almost the same as for a front driven and a back-driven car. Both have their advantages and disadvantages. If you now mix them --> 4x4 driven car you not only combind the advantages of both generations but also the disadvantages... and that's the big problem for the Hammer CPU generation, it includes all the letdowns the x86 archictecture always had...
April 9, 2003 11:23:23 PM

Ok, thanks for the info. Itanium 2 is my way to go. Heh, just kidding...if I were rich though...

Sounds very impressive though. So you're saying that with true 64-bit programs, the Itanium 2 will perform at 200% of what it would if it was a 32-bit CPU running 32-bit programs? I stand stunned and amazed.. ;) 

Like I said I know very little about the differences between 32/64 bit, but I hear ya ;) 

Itanium 2, 4 gb memory, geeze...
April 10, 2003 12:37:43 AM

no, as you probably know, a 3.2GHZ P4 is not twice as fast as a 1.6 GHz but probably only a 30-40% faster. The same applies to real 64-bit CPUs. Of course the Hammer CPU doesn't really come anyhow near that performance. In fact in Floating Point operations (where the Athlon XP shines over the P4), the Intel Itanium beats the Opteron without any problems.

Even the Athlon 64 can only run 32-bit programs a small degree faster, but the Prescott will probably perform better for 32-bit applications... Don't expect only 64-bit OSes with only 64-bit programs and only 64-bit games next year. It won't happen. 32-bit has still a long live to life
April 10, 2003 12:42:54 AM

I understand.

No, of course 64-bit only games would take a few years to become industry standard, if ever. I suppose that's what you meant be saying most consumers don't need it yet.

Just one thought. Imagine...a MP motherboard that operated two CPU's. Not too out-of-this-world, right? But here's the thing. CPU 1: Prescott, 4 GHz. CPU 2: Itanium 2, 1 GHz. Now this setup would yield from: CPU 1: Exclusive 32-bit performance. CPU 2: Exclusive 64-bit performance.
Now wouldn't this setup sound pretty much like...perfect performance? I'm sure this combo wouldn't even be possible, but if it were, to me this sounds...perfect ;) 

<P ID="edit"><FONT SIZE=-1><EM>Edited by sabbath1 on 04/09/03 08:47 PM.</EM></FONT></P>
April 10, 2003 2:08:38 AM

Quote:
The reason for this is that a real 64-bit CPU can do 64-bit work much better than 32-bit/64-bit hybrid because it's only purpose is 64-bit and not some mélange of different CPU generations trying to do the best of two different worlds!

What are you talking about? "Real 64 bit CPU" Either the CPU has 64 bit registers or not. You obviously have no real idea on how the x86-64 works. Sure it's not EPIC but it has just as much 64-bit capabilities. EPIC is not exactly VLIW but that has nothing to do with its ability to execute code efficiently. Sure clock for clock IA64 will always execute more IPC as that is by design of VLIW. Conversely, IA64 will always need huge caches to feed its execution units. In the end, the reason x86-64 will do well is its expanded register set and its unique crossbar memory architecture.

Dichromatic for your viewing plesure...
April 10, 2003 3:10:33 AM

You know your onto something. Talking CPU thats what we need. Now we will be able to get the rest of story on whats going on with CPU's themselves. Direct from the Horses mouth. Or should I say from the mouth of CPU.
April 10, 2003 7:45:32 AM

The Itanium performs good because it has a exceptionally well designed 3 level cache system and an instruction set that is designed to get a large amount of parallelism. The fact that it's 64 bit has very little to do with its performance. Most of its performance is based on its compilers ability to schedule non-dependant instructions to run in parallel without having to rely on complex instruction decoders. As for its ability as a game machine, it would most definitely fall well behind the rest of the CPUs, as its dynamic branch prediction is almost nonexistent.

Dichromatic for your viewing plesure...
April 10, 2003 11:24:22 AM

But if a game was designed with 64-bit code exclusively, wouldn't that game run good on the Itanium 2 then?
I know 32-bit gaming sucks on it, because 32-bit is not supported by the CPU, only emulated, leading to similar performance to that of a Pentium 1 200 or the like.
April 10, 2003 5:22:56 PM

no

[-peep-] french
April 10, 2003 5:28:36 PM

all point of I2 are good, exception to software that are still not mature far from it.

I2 FPU work 2 faster on 32 that on 82 bit.

I2 instruction size 41 bit
I2 data ALU 64 bit (that why i got a '''lower''' perf that others RISC on ALU)
I2 FPU data 82 bit or 32 bit

[-peep-] french
April 10, 2003 5:39:29 PM

Quote:
But if a game was designed with 64-bit code exclusively, wouldn't that game run good on the Itanium 2 then?
I know 32-bit gaming sucks on it, because 32-bit is not supported by the CPU, only emulated, leading to similar performance to that of a Pentium 1 200 or the like.


For 64-bit code to be used, there has to be a need for 64-bit code to begin with. If you have no need for 64-bit data types in your program (and no game today, or in the next 5 years at least will), going "64-bit" won't help at all. If anything, if you use 64-bit data types when you don't need it, you'll take up more cache than you should and slow down performance.
What people don't seem to understand is that "64-bit" only applies to the GPR's. Floating pointer operations, something games of today and the future rely heavily on, does not change. A P4 does the same types of FP operations as the Itanium2 which does the same type of FP operations as the Opteron. The Itanium2 merely has more parallel execution resources and an ISA to take advantage of those. So it can do more FP operations per clock (on average). Of course, code must be written to take advantage of this parallelism in the ISA.
As for other software that's integer-dependent. There, again, has to be a need for 64-bit integers. How many programs do you know deal with numbers bigger than 2 billion? Most programs are a whole lot of little operations (i.e. 1+2, 54+20, etc), not big operations (you rarely need to add 2 billion to 2 billion in any program). In those cases, 64-bit operation brings absolutely no benefit to calculation speed. Again, it will just take up more space in cache.
Then there's the ability to address more then 4 GB of memory. This is probably the only real advantage I can think of and most needed in the future. Opteron has a very good chance against the Xeons in the entry-level server market because of this ability. For desktops. How many of you absolutely need more than 4GB of memory right now?

"We are Microsoft, resistance is futile." - Bill Gates, 2015.
April 10, 2003 5:47:22 PM

Quote:
What people don't seem to understand is that "64-bit" only applies to the GPR's. Floating pointer operations, something games of today and the future rely heavily on, does not change.

Hmm ... actually you <i>could</i> theoretically use the 64-bit integers <i>as</i> floats with pretty good accuracy just by saying all values are multiplied by X. It couldn't be done well with 32-bit integers because their value range was too short for a high decimal accuracy, but I bet it could be done with 64-bit integers. Imagine how fast a game that used only the ALU could be.

<font color=blue><pre>I'm proud to be an American,
who served my country in the US Air Force,
to protect the rights of my fellow Americans,
to hold protests against others like me.</pre><p></font color=blue>
April 10, 2003 6:33:03 PM

The extra precision on FPU can help on speech stuff and 3DS rendering to a sacrifice of perf

[-peep-] french
April 10, 2003 6:38:08 PM

Quote:
Hmm ... actually you could theoretically use the 64-bit integers as floats with pretty good accuracy just by saying all values are multiplied by X. It couldn't be done well with 32-bit integers because their value range was too short for a high decimal accuracy, but I bet it could be done with 64-bit integers. Imagine how fast a game that used only the ALU could be.


This was the same argument made to use 32-bit integers instead of FP32 (or was it FP16) data types. The fix-point method died long ago. It was found that with modern out-of-order, superscalar, pipelined MPU's, no matter how fast you made the fix-point operations, they won't be as flexible or as fast as just using FP. 64-bit data types for games is nothing new. Consoles used them back in the days of N64 and Jaguar. I think you'll agree the results in terms of graphics in those games weren't exactly spectacular. Fix-point is a bitch to work with and the resulting precision isn't exactly to die for. As for the added speed. FP operations are pretty fast on modern MPU's. To be able to emulate FP operations using the fix-point method would require more operations be carried out in parallel and the benefits of integer-operation would be negligible, if existent at all.

"We are Microsoft, resistance is futile." - Bill Gates, 2015.
April 10, 2003 8:45:47 PM

Quote:
It was found that with modern out-of-order, superscalar, pipelined MPU's, no matter how fast you made the fix-point operations, they won't be as flexible or as fast as just using FP

As flexible, no. As fast, hell, it <i>should</i> be even faster <i>if</i> done right.

Quote:
Consoles used them back in the days of N64 and Jaguar. I think you'll agree the results in terms of graphics in those games weren't exactly spectacular.

That's hardly a fair way to judge it. We're talking about ultra-cheap 3D hardware on what can now be considered 'old' platforms. For the amount of money involved and the state of technology at the time, I think their graphics were quite spectacular.

Quote:
Fix-point is a bitch to work with and the resulting precision isn't exactly to die for.

I've worked with it and agree that it's difficult in that getting into the mentality of always thinking in fixed-point is difficult, but once you overcome that, it's not so bad. As for the precision, I agree it isn't great, but with a 64-bit integer you have to admit that the precision would almost always be at least in the range of 'acceptable' now. With 32-bit that was a stretch. With 16-bit it was a joke. With 64-bit though, it's really not so bad.



Quote:
As for the added speed. FP operations are pretty fast on modern MPU's.

I won't argue there, at least as long as you avoid the P4's x87...

Quote:
To be able to emulate FP operations using the fix-point method would require more operations be carried out in parallel and the benefits of integer-operation would be negligible, if existent at all.

Here I have to disagree. It all depends on how it's done. The software that I have that uses fixed-points requires about 3% more operations. And it crunches numbers exceedingly quickly. (Not incredibly accurately as it's 32-bit code, but quickly at least.)

Granted, I personally didn't write that code and I'd have probably just used floats had I written it myself. Still, it worked there. I don't see why it wouldn't work elsewhere.

<font color=blue><pre>I'm proud to be an American,
who served my country in the US Air Force,
to protect the rights of my fellow Americans,
to hold protests against others like me.</pre><p></font color=blue>
April 10, 2003 11:05:03 PM

You guys must not forget that 64-bit means 64 logical operations in one instruction. One of the key features of x86 is its ability to test and retrieve bits from a register, alter, and report on their position, as found in the instructions BSF, BSR, BT, BTC, BTR, and BTS, (Bit Scan Forward, Bit Scan Reverse, Bit Test, Bit Test and Complement, Bit Test and Reset, Bit Test and Set, respectively). Math in integer is a total waste of time, as logic in floating point is just as useless. There are exceptions to these rules but haven't we all at one point in our engineering endeavors used a wrench as a hammer (no x86-64 reference intended).

Dichromatic for your viewing plesure...
April 11, 2003 12:55:47 AM

Quote:
That's hardly a fair way to judge it. We're talking about ultra-cheap 3D hardware on what can now be considered 'old' platforms. For the amount of money involved and the state of technology at the time, I think their graphics were quite spectacular.


Compare it to the Playstation, which used FP32 for precision. It was just as fast, had better precision, and code was much easier to write for it.

Quote:
I've worked with it and agree that it's difficult in that getting into the mentality of always thinking in fixed-point is difficult, but once you overcome that, it's not so bad. As for the precision, I agree it isn't great, but with a 64-bit integer you have to admit that the precision would almost always be at least in the range of 'acceptable' now. With 32-bit that was a stretch. With 16-bit it was a joke. With 64-bit though, it's really not so bad.


For FP32 precision......maybe. But we're in that point where we're moving to FP64 precision. Perhaps not for games anytime soon, and using 64-bit integers might be possible, but I don't think the speed would be that much greater. Of course, I've had absolutely no experience with fix-point methods (before my time) so I can't comment, but it would seem to me that it would either:1
1. take up twice the data space as FP would or
2. Us a lot of bit-wise operations, which can be abismally slow and require the math to be done separately for each component of the bit-segment.

You could, of course, just not use partial values at all and use whole-values but just on a very large scale. But I can see this becomming quite a hassle.

Quote:
I won't argue there, at least as long as you avoid the P4's x87...


The P4's x87 resources actually aren't that bad. The same as the P3 actually. The only thing you have to avoid is shifting operations. Such a thing could easily be done with one or two add operations instead and would perform much faster.

Quote:
Here I have to disagree. It all depends on how it's done. The software that I have that uses fixed-points requires about 3% more operations. And it crunches numbers exceedingly quickly. (Not incredibly accurately as it's 32-bit code, but quickly at least.)


You have to wonder how much precision they sacrificed (even compared to FP16) in order to gain that kind of performance. Remember, the P4 only has twice the parallel execution resources for integer as it does for x87 (and its SSE/SSE2 resources are twice as much as those for integer) and the Athlon only has 50% more. And more often than not, you're going to find that you can't execute many fix-point related operations in parallel.

"We are Microsoft, resistance is futile." - Bill Gates, 2015.
April 11, 2003 12:14:29 PM

Quote:
For 64-bit code to be used, there has to be a need for 64-bit code to begin with.

I know one group of examples where 64-bit integer power can be very usefull: Distributed computing. Take for example the <A HREF="http://www.distributed.net" target="_new">distributed.net</A>-project. They are currently working on a 72-bit key. I also know this is all integer work. So having a 64-bit integer processor would be very powerful here.
But actually, and I've said that before, all current processors are capable of 64-bit integer math: MMX is the clue. MMX is nothing less than an instruction set for working on 64-bit operandi. Most of the times, though, it is used to work on two sets of 32 bits, or four sets of 16 bits at a time. In essence, though, it really is 64-bit integer math.
I don't kow wether this is currently implemented in the x86-64 instruction set, but maybe the 64-bit integer capabilities of the Hammer could be used, as is done with MMX, as a parallel of two 32-bit ALU's. It is just an idea, but this way, there are many ways in which can be taken advantage of the 64-bit ALU's of the Hammers.
Though I have to admit that in fact there isn't a really big need for 64-bit computing power on our desktops, and there won't be in the near future. In the workstation- and server-area, I think cheap 64-bit solutions will be welcomed with open arms.

Greetz,
Bikeman

<i>Then again, that's just my opinion</i>
April 11, 2003 4:18:23 PM

Quote:
I know one group of examples where 64-bit integer power can be very usefull: Distributed computing. Take for example the distributed.net-project. They are currently working on a 72-bit key. I also know this is all integer work. So having a 64-bit integer processor would be very powerful here.


Yes, as AMD has mentioned, cryptology is one of the areas in which 64-bit computing would be useful. However, how many people spend $2000 on a machine to run RC-5 better?

Quote:
But actually, and I've said that before, all current processors are capable of 64-bit integer math: MMX is the clue. MMX is nothing less than an instruction set for working on 64-bit operandi. Most of the times, though, it is used to work on two sets of 32 bits, or four sets of 16 bits at a time. In essence, though, it really is 64-bit integer math.


This is not true. MMX's operand size are still 32-bit in terms of integer. MMX merely works on vectors of 2 32-bit integers, but they are still 2 integers, not 1.
SSE and SSE2, however, has the capability to operate on 64-bit integer operands. The thing is though, it's limited to add/mul instructions for now. There is a lot of functionality mission that you'd normally have with integer operations. Most of encryption calculations have to do with logical and bit-wise operations anyway, and SSE/SSE2 is lacking in these departments when it comes to working on 64-bit operands.

Quote:
I don't kow wether this is currently implemented in the x86-64 instruction set, but maybe the 64-bit integer capabilities of the Hammer could be used, as is done with MMX, as a parallel of two 32-bit ALU's. It is just an idea, but this way, there are many ways in which can be taken advantage of the 64-bit ALU's of the Hammers.


As I said before, MMX is really an SIMD vector of 2 32-bit integers operations. It doesn't produce the same result as a 64-bit add. An add operation on an MMX SIMD vector produces the result of an SIMD vector (i.e. 2 32-bit integers, not one 64-bit integer). It is possible, with some additional instructions (and hence, processing time), to use this to emulate <b>some</b> 64-bit integer operations, but that's restricted to simple adds really. It is not a complete solution.
The ALU's on Hammer, when operating on a 64-bit integer operand, produces a 64-bit integer operand, not 2 32-bit integer operands. In the cases in which you emulate 2 32-bit operations, you'd need to do extra work to convert that operand result into 2 32-bit integers anyway. In that extra time, you could've very well done 2 32-bit integer operations to begin with. It would've taken less time and less effort on the programmer's part.

Quote:
Though I have to admit that in fact there isn't a really big need for 64-bit computing power on our desktops, and there won't be in the near future. In the workstation- and server-area, I think cheap 64-bit solutions will be welcomed with open arms.


True, but mainly because of the expanded memory capacity. There is very little need, even in the workstation market, for 64-bit integer math. This is an issue Intel needs to address, and having physical address extension isn't going to do it. I guess this is why they're producing Deerfield soon as a cheap, workstation-level processor.

"We are Microsoft, resistance is futile." - Bill Gates, 2015.
April 12, 2003 7:47:35 AM

Quote:
This is not true. MMX's operand size are still 32-bit in terms of integer. MMX merely works on vectors of 2 32-bit integers, but they are still 2 integers, not 1.

Just did some searching on Google: Behind <A HREF="http://www.tommesani.com/MMXPrimer.html" target="_new">this link</A> you can find these words:
<i>"MMX technology introduces four new data types: three packed data types and a new 64-bit entity. Each element within the packed data types is an independent fixed-point integer. The architecture does not specify the place of the fixed point within the elements, because it is up to the developer the control of its place within each element throughout the calculation. This adds a burden on the developer, but it also leaves a large amount of flexibility to choose and change the precision of fixed-point numbers during the course of the application in order to fully control the dynamic range of values. The four MMX technology data types are:
Packed byte -- 8 bytes packed into one 64-bit quantity
Packed word -- 4 16-bit words packed into one 64-bit quantity
Packed doubleword – 2 32-bit double words packed into one 64-bit quantity
<b>Quadword -- one 64-bit quantity</b>"</i>

I also looked at the overview of the MMX instructions provided on that website, and there, actually, they do confirm what you say: Add, substract and multiply-instructions only work on 32-bit operandi packed in 64 bits. So there is no carry-transfer between the lower 32 bits and the upper ones. Logical instructions, though, can work on 64 bits at a time, as MOV-instructions can.

So actually, you are right imgod2u, and I should probably not have posted this. But ok, I did the searching, so why not post this ...

Greetz,
Bikeman

<i>Then again, that's just my opinion</i>
April 12, 2003 12:27:39 PM

There's logical and, or and exclusive or for quadword data types, however, the description for MOVQ is, "transfers 64-bits of <b>packed</b> data from memory to an MMX register". This does not mean it has to operate on a quadword data type (although MMX does allow that). However, as I noted before, there are no arithmetic instructions available. There are, however, simple add and mult instructions available for quadword operands in SSE/SSE2.

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

Watermelons are Kool. But!!!! Lifes a bowl of cherries.
April 13, 2003 9:47:07 AM

A box of chocolates, you mean by no doubt ...

Yeah, yeah, I'm sorry I spoiled this thread ...

<i>Then again, that's just my opinion</i>
April 13, 2003 10:44:04 AM

NERDS!

blah.. siggys suck
April 13, 2003 12:45:10 PM

:eek: 

<i>Then again, that's just my opinion</i>
April 13, 2003 2:17:44 PM

That's geeks! Nerds learn Japanese and study math. Geeks speak Klingon!

"We are Microsoft, resistance is futile." - Bill Gates, 2015.
April 13, 2003 4:19:30 PM

I'm don't even speak Klingon ... Now I'm not a nerd, nor a geek ...

:frown: I need an identity!! Help me ... :frown:

<i>Then again, that's just my opinion</i>
April 13, 2003 5:30:56 PM

You're just an outcast I guess. A shame.

"We are Microsoft, resistance is futile." - Bill Gates, 2015.
April 13, 2003 6:39:36 PM

Ow ...

Thank you very much ...
I'll ... I'll .. I'll ...


:lol:  Just kiddin'! :lol:  I do know who and what I am, and actually I am kind of proud of it. No, and it's not a geek or a nerd ... :tongue:

Greetz,
Bikeman
PS: I apologize again for wasting precious database-storage on this forum, but you know ... I just felt like it ...

<i>Then again, that's just my opinion</i>
!