Anyway, let's conclude that I will continue to support what works for me. As I said as long as I'm getting a cheap CPU that I can program better than Intel machines costing much more, it's quite easy to use them and get more performance.
Posted on 2004-05-18 13:57:42 by bitRAKE
...
Posted on 2004-05-18 14:02:05 by Scali
If you look on the board you'll see that I've optimized code for Intel CPUs that superseeds published Intel code. Easily leading to the conclusion that my code is not inadequate on Intel CPUs. Additionally, I have been optimizing for Intel CPUs much longer than AMD CPUs.
Posted on 2004-05-18 14:11:33 by bitRAKE
I can beat published Intel code easily aswell. Just take some MMX code of theirs, double it up with SSE2, et voila. The MMX code was obviously written at a time when SSE2 was not available, so hey.
That's not the point. The point is to get the most out of the processor for the task at hand. And if you do so, you can often use extra instructionsets on Intel, that AMD has not yet implemented... Currently AMD does have an SSE2 implementation on one of their CPUs (Intel has it on all CPUs), but it's not that competitive with the Intel one, so Intel still has the advantage.
I don't quite see your claims of AMD being faster. The only explanation is that it's not using all the features that the CPU offers properly. Are you trying to make the Intel CPUs work within the limitations of AMD CPUs?
Posted on 2004-05-18 14:18:50 by Scali



There WAS a big difference. But perhaps you have forgotten about Hyperthreading already? HTT CPUs are nice and responsive aswell, even under heavy load. Also, your example of editing while compiling is nice, but the editor is hardly making use of that second CPU. Therefore it is not very cost-effective. Another reason to prefer HTT ;)


I'm running an HT uniprocessor right now. Nowhere near as nice as a dual CPU. I wish I'd gone ahead and spent the extra bucks to get a dual Xeon system than a HT PIV system. As to whether that editor is making use of the second CPU or not, it really doesn't matter. When I'm compiling, my single CPU (with HT) stalls and stutters, when I have two CPUs it doesn't. As for being cost effective, well, I tend to purchase my CPUs many years apart and I tend to buy high-performance systems (SCSI, fast bus, fast video, etc., etc.) with each iteration so that I'm not replacing boxes every couple of years (I tend to require a 10x performance boost before purchasing a new computer - E.g., I recently upgraded from a 300 MHz PII to a 3+GHZ PIV). By the time I've reached the end of the performance curve on my computer system, that dual-CPU system has paid for itself many times over as I haven't had to upgrade anywhere near as often. Quite frankly, my two-CPU PII system, at 300 MHz with fast&Wide SCSI drives beats many of the "sub-$500" 2+GHz systems available today. As always, CPU speed is only one part of the equation, system design is the most important element. And having two CPUs nearly *doubles* the lifetime of a computer system for someone who uses computers the way I do (i.e., several concurrent programs running, such as editors, compilers, build tools, IDEs, and so on).
Cheers,
Randy Hyde
Posted on 2004-05-18 14:52:23 by rhyde
When I'm compiling, my single CPU (with HT) stalls and stutters, when I have two CPUs it doesn't.


You are using Windows XP?
Also, considering the price-difference (HTT is 'free', and even a single CPU that is suitable for multi-CPU operation is many times more expensive than a regular one), I don't think it's fair to compare. You can buy 2 single-CPU systems for the price of one dual system, and have money to spare, usually. And then you can also edit and compile at the same time, so what's your point? :)
HTT is a great improvement over single-thread CPUs anyway, especially at the price.

Quite frankly, my two-CPU PII system, at 300 MHz with fast&Wide SCSI drives beats many of the "sub-0" 2+GHz systems available today.


I sincerely doubt that.
Even the best SCSI disks available at that time are no match for budget IDE drives today. And all other components are considerably slower aswell. ...

And having two CPUs nearly *doubles* the lifetime of a computer system for someone who uses computers the way I do (i.e., several concurrent programs running, such as editors, compilers, build tools, IDEs, and so on).


For you perhaps. For me it's different. I only work on one program at a time, so compiling and editing are mutually exclusive. Also, I only run one performance-critical application at a time. Everything in the background is exactly that, in the background. It doesn't need much CPU at all (idle browsers, mailclients etc), and it would be a total waste to have a second CPU for it.
I think my way of working is common for a (software) engineer. At any rate, for me, only the speed of one CPU matters, everything else is waste. And 64 bit is waste aswell, for now. My datasets aren't that large.
Posted on 2004-05-18 15:13:12 by Scali

I don't quite see your claims of AMD being faster. The only explanation is that it's not using all the features that the CPU offers properly. Are you trying to make the Intel CPUs work within the limitations of AMD CPUs?
I use all the features for the CPU I'm programming for.
Posted on 2004-05-18 15:50:45 by bitRAKE
Originally posted by another_old_member

You are using Windows XP?

Yes.


Also, considering the price-difference (HTT is 'free', and even a single CPU that is suitable for multi-CPU operation is many times more expensive than a regular one),

HTT was not free. I (actually, a friend of mine) paid a considerable premium to get that HTT enabled CPU over a cheaper 2.6 GHz device. From all the benchmarks I've seen, a HTT CPU is about 10-20% faster than the same CPU with HT turned off. On dual CPU systems, you can achieve almost 100% faster. Quite a difference.



I don't think it's fair to compare. You can buy 2 single-CPU systems for the price of one dual system, and have money to spare, usually. And then you can also edit and compile at the same time, so what's your point? :)

You can buy two *very* low-end systems for the price of one high-end dual CPU system. .... For example, on my home system I currently have a 2.6GHz CPU (no hyperthreading) because *it* is so much more cost effective than the 3.2 GHz CPU with very little noticeable difference in performance (I've compared my system against a friend's 3.2 GHz system to determine when it would be cost effective to switch out my 2.6 for a 3+GHz+HT CPU). The difference between my machine and his is nothing like the difference I saw on the dual-Xeon system I was using for some contract work six months ago).

Of course, today memory speeds and disk speeds are where the bottleneck is, but the nice thing about dual CPU systems is that you also get twice as much L1 and L2 cache (and the Xeon CPUs found in Dual CPU systems usually come with more cache to begin with).



HTT is a great improvement over single-thread CPUs anyway, especially at the price.

As I've said, benchmarks show about a 10%-20% improvement (not mine, I've never bothered to scientifically benchmark the machines, but I *have* noticed that the system stutters under load, which I didn't get with a dual Xeon system I had at one time). As for the price, if you want higher performance, you pay more money. If getting a rock-bottom price is your most important goal, then a dual-CPU system is not for you.


I sincerely doubt that.
Even the best SCSI disks available at that time are no match for budget IDE drives today.

Are you just reading specs? Or have you actually used fast & wide SCSI drives?
There is a considerable difference. Budget IDE drives may have numbers like 133 on them, that doesn't mean that they're fast. Even at only 20MHz, a 10,000 RPM SCSI drive walks all over today's "budget" IDE drives. SATA is another story, but I don't consider them "budget". Not yet, anyway.


And all other components are considerably slower aswell. You'd have to do something really stupid to make a 2+ GHz system run slower than that. I think you're exaggerating considerably here.

Yes, and most "budget" systems have some really stupid designs. I have a 2.6GHz system at home that is about three times faster than a 2.0 GHz system at work. The 3.2 GHz system I use is slower than my 2.6 GHz machine (because the 2.6GHz system has the high-end periperhals, memory bus, etc.). My 300 MHz PII system is generally clocking in at about 1/2 the speed of the 2.0 GHz system. Yes, designers do *stupid* things on low-end machines (like the 2.0 GHz machine I have at work).



For you perhaps. For me it's different. I only work on one program at a time, so compiling and editing are mutually exclusive. Also, I only run one performance-critical application at a time. Everything in the background is exactly that, in the background. It doesn't need much CPU at all (idle browsers, mailclients etc), and it would be a total waste to have a second CPU for it.
I think my way of working is common for a (software) engineer. At any rate, for me, only the speed of one CPU matters, everything else is waste. And 64 bit is waste aswell, for now. My datasets aren't that large.

Well, no one can tell *you* what machine is best for you. ....

Heck, I could eschew the graphical environment and dramatically increase my compile and editing times if I only wanted to do one main-line task at a time. I'd rather buy the second CPU and make GUI development work real well for me... That would be the difference between us, I suppose. I find the solution to be quite cost effective, personally.
Cheers,
Randy Hyde
Posted on 2004-05-18 15:55:38 by rhyde
I use all the features for the CPU I'm programming for.


... my experiences are that the Intels are faster if you bother to write specific code for them. Some of the code that f0dder and I have posted here over the years, proves that, and there are plenty of real-world examples, such as LightWave.
Posted on 2004-05-18 15:59:48 by Scali
HTT was not free. I (actually, a friend of mine) paid a considerable premium to get that HTT enabled CPU over a cheaper 2.6 GHz device.


I didn't say 'was', I said 'is', since you cannot buy CPUs without HTT anymore, I think, and HTT CPUs have always been in the same pricerange as non-HTT CPUs, unlike multi-CPUs such as Xeon and Opteron.

On dual CPU systems, you can achieve almost 100% faster. Quite a difference.


Firstly, obviously since you spent more than 100% the extra money, you obviously get more performance. Secondly, you will NOT get an almost 100% faster system for a single application. In the worst case (a single-threaded application), there is no advantage at all, and the second CPU is idle.
In the average case (multiple threads, but one main-thread which does most of the work), you will get slightly better performance, but probably not that much more than HTT would give you.
Only in the best case, where your application can be parallelized and run on two CPUs simultaneously (without inducing extra overhead!), you would get 100% gain. But that is rare, very rare. Only a small subset of applications lends itself for such implementations.

Anyway, the discussion was more about dual Opteron vs P4. Dual Opteron would obviously be better than a single Opteron. And discussing HTT for P4/Xeon is useless aswell, since a multi-CPU Xeon machine will still offer HTT aswell.
The point is more that a P4 is faster than an Opteron, and offers HTT, so it can offer some of the advantages of a dual-CPU system, while also offering a faster pipeline. And this scenario is probably the most attractive one in the average case. It is in my case anyway.

The difference between my machine and his is nothing like the difference I saw on the dual-Xeon system I was using for some contract work six months ago.


Again you generalize your situation. You may have used parallel code. I don't. Single or dual makes no difference.

but I *have* noticed that the system stutters under load, which I didn't get with a dual Xeon system I had at one time


A dual system with 2 heavy threads will still stutter as much. It's only relative.

Are you just reading specs? Or have you actually used fast & wide SCSI drives?


I actually have some old SCSI-only box here, a Pentium Pro 200. Should be from around the same era as your PII-system. The SCSI disk is a complete joke compared to what I have in my current PC (which is also about 3 years old by now).
...
Also the only difference between SATA and IDE for some (most?) disks is an integrated converter on the circuitboard.

Yes, and most "budget" systems have some really stupid designs. I have a 2.6GHz system at home that is about three times faster than a 2.0 GHz system at work. The 3.2 GHz system I use is slower than my 2.6 GHz machine (because the 2.6GHz system has the high-end periperhals, memory bus, etc.). My 300 MHz PII system is generally clocking in at about 1/2 the speed of the 2.0 GHz system. Yes, designers do *stupid* things on low-end machines (like the 2.0 GHz machine I have at work).


Be specific for a change? WHAT is it slower at, and WHY? What's so stupid about the design?
Also, you seem to think that performance scales linearly with clockspeed or something? Because your dual PII 300 is half as fast as a 2 GHz system, the 2 GHz system is worse? It doesn't work that way. Not by a long shot. As you said yourself, the CPU is only one small factor. The CPU is the thing that scaled beyond a factor 2. But what about memory, chipsets, PCI buses etc? Eg if they both use 100 MHz SDRAM modules, I don't find it strange at all that the 2 GHz system would be barely faster with memory-intensive tasks. What choice does it have?

But to argue that dual CPU systems have no benefits, or that 64-bit machines offer no benefit because of your specialized usage patterns is not a very solid way to make an argument.


...
I haven't actually heard anyone mention any decent benefits of 64-bit machines at all.
As for multi-CPU, well, we just get the obvious story that if your app is parallelizable, throwing more threads/CPUs at it, will make it faster. But then we can also throw the usual stories at it that you cannot scale CPUs endlessly (this has been proven by people before, no need for me to reiterate all that), and that parallelizable applications are scarce.
A discussion that has been held many times before. ...
So the conclusion is that we will need to continue to make faster pipelines, if we want to continue to increase performance across the board.

And assuming that your working habits are common for software engineers may be a bit of a stretch, too.


It's not an assumption. If I look at the people I work with, I see the same patterns. If I talk to other engineers, I again notice the same patterns.

That would be the difference between us, I suppose.


Yes....
Posted on 2004-05-18 16:21:26 by Scali
I have a dual cellery 550 BP6 running right now. With a modern video card it is just as responsive as any other system I've used. I bought the motherboard with CPU's off eBay for $300 in 2000, been using it ever since. It has been a real pleasure using such a solid machine for so many years.
Posted on 2004-05-18 20:42:21 by bitRAKE
I have much the same view on buying hardware as Randy has, build it out of reasonable stuff first time, add waht you like to it along the way and you usually get some years out of it in capacity terms. Current DEV box is a 2.8 gig PIV but I spent the money on a high end Intel 800 meg FSB board and 2 gig of ddr400 memory. the two SATA drives seem reasonable and I shoved a pair of IDE drives as the second pair as I had them as spares.

Win2k sp4 treats the hyperthreading hardware as 2 processors and the main performance problems are working out how to turn off the most junk in win2k.

Many people make the same mistake of simply chasing the highest number with processor clock speed and end up with a crappy main board, not enough memory and lousy disk IO with the rest. I have a 600 PIII with dual scsi's that simply ate the stuff around at the time alive, it was that much faster and while clearly off the pace for high end stuff at the moment, it is still a reasonable box to work with as all of its peripherals were good stuff at the time. Its not all that often that you can use a box that is 5 years old for current work unless it was well thought out when it was built.

Intel have already made noises about the limitations of the current PIV core in heat terms and Scali is right that the M core is derived from notebook computers for exactly the reason why the PIV core is near its end, power consumption and heat dissipation. The Intel plant in Israel seems to be doing the development work on that particular core at the moment.

Anyone who need high end desktop stuff at the moment is probably well served by using dual Apple G5 hardware as it has the processor grunt and the capacity to use larger amounts of memory than is not possible with current PIV technology.

The only thing that has kept x86 hardware alive for so long is backwards compatibility with existing software and this is the main leverage the consumer market have on both Intel/AMD and Microsoft. If their new stuff won't run their existing software, they won't buy it.

Hardware like the AMD Opteron is actually cheaper in spending terms than the first IBM PC so 64 bit x86 compatible hardware is already with us and like most things, it will only get better where a lemon like the Itanium will slowly fade away because of its cost and unimpressive performance. Its main failing was its poor performance on x86 code.

We all know that 64 bit hardware predated x86 but we are on the threshold of 64 bit cheap hardware now so its succession is inevitable. It will probably take some years to get up and going but so did 32 bit.
Posted on 2004-05-18 22:04:20 by hutch--



I didn't say 'was', I said 'is', since you cannot buy CPUs without HTT anymore, I think, and HTT CPUs have always been in the same pricerange as non-HTT CPUs, unlike multi-CPUs such as Xeon and Opteron.

...My experiences at the local computer fair suggest something completely different, however. (see http://www.lacomputerfair.com).



Firstly, obviously since you spent more than 100% the extra money, you obviously get more performance. Secondly, you will NOT get an almost 100% faster system for a single application. In the worst case (a single-threaded application), there is no advantage at all, and the second CPU is idle.

Of course you get better performance by spending more money. I believe that was my point. The reason dual CPU systems cost twice as much has more to do with *system* design than CPU cost. After all, and I'm sure you'll agree, it doesn't make any sense to surround a dual-CPU system with cheap, low-performance, peripherals.


In the average case (multiple threads, but one main-thread which does most of the work), you will get slightly better performance, but probably not that much more than HTT would give you.

I've used both dual-CPU systems and HTT systems. Recently. The dual-CPU systems are much faster. ...


Only in the best case, where your application can be parallelized and run on two CPUs simultaneously (without inducing extra overhead!), you would get 100% gain. But that is rare, very rare. Only a small subset of applications lends itself for such implementations.

Again, I never made a claim about a single program doubling in speed. My claims have always been that I can run an aggregate of processes twice as fast. SMT does *very* well when running multiple processes. You don't need special software for that, only OS support.


Anyway, the discussion was more about dual Opteron vs P4. Dual Opteron would obviously be better than a single Opteron. And discussing HTT for P4/Xeon is useless aswell, since a multi-CPU Xeon machine will still offer HTT aswell.

Yes, I would agree that having a dual-CPU system, with each CPU supporting HTT would be better still.


The point is more that a P4 is faster than an Opteron, and offers HTT, so it can offer some of the advantages of a dual-CPU system, while also offering a faster pipeline. And this scenario is probably the most attractive one in the average case. It is in my case anyway.

But would a PIV, with HTT, be faster than a dual or quad Opteron running multiple processes? Again, it depends upon your usage patterns. But in general, I would say yes. Unless AMD processors are running at half the speed of Intel processors (which may very well be, I don't know).



Again you generalize your situation. You may have used parallel code. I don't. Single or dual makes no difference.

The only parallel code I use is the OS. I simply run multiple programs concurrently. About the closest thing I have that does parallel operation is GNU make (which will do builds in parallel, though no single compiler is multi-threaded).




A dual system with 2 heavy threads will still stutter as much. It's only relative.

A dual system will not stutter as much. It will stutter half as much :-). Clearly, stuttering can still occur if your load average rises too high, but the bottom line is that I can, for example, do a build of the HLA system while continuing to use a dual-CPU system for other work. On a single CPU system, you get *very* noticeable pauses in a foreground process like an editor. Even with HTT, this is very noticeable.



I actually have some old SCSI-only box here, a Pentium Pro 200. Should be from around the same era as your PII-system. The SCSI disk is a complete joke compared to what I have in my current PC (which is also about 3 years old by now).

Just like IDE, there is a wide variety of SCSI devices. Some good, some not-so-good. I still have some Mac II systems laying around with 5Mhz 8-bit SCSI devices. Modern IDE drives blow those guys away, too. My PII system has fast&wide, 10,000 RPM SCSI-II drives. .... My modern system has a SCSI-320 controller with two 15,000 RPM drives running in a RAID configuration. The drives are quite a bit faster than the ATA-133 drives that I use to back them up (several times faster, in fact).


You seem to think that things like 'SCSI' and 'dual-CPU' are something magic, which make your systems dozens of times faster than others. Keep your fairytales to yourself.

Really? When did I say "dozens"? The only numbers I remember quoting are two and three times as fast.


Also the only difference between SATA and IDE for some (most?) disks is an integrated converter on the circuitboard.

I would even agree with "most" in this context, at the current time. I'm assuming that if someone is interested in putting together a high-performance system, they won't buy just any disk drive and expect decent performance from it. Instead, they do their homework and do a little research before making the purchase. Yes, you can buy some "SATA drives in sheep's clothing" if you want to save a few bucks. But if you're interested in a high-performance system, you have to do a little better than that. And if you *really* want high performance, you get a SCSI-320 controller and run RAID (which is what I do on my 2.6 GHz system; and, yes, running RAID pretty much doubles your performance under SCSI, so that the 320 MB/sec data transfer rate isn't quite a "fairy tale").


...


WHAT is it slower at, and WHY?

When I compile large systems, everything else (browsing, email, editing, photo processing, and anything else I decide to do) slows down *considerably*.

Why is it slower? Because the single CPU is busy doing the compile (which is largely compute-bound, thus sucking up the CPU cycles like mad) leaving few CPU cycles for the other processes which are often I/O bound (and, thus, lose their time slice shortly after getting it).

I.e., the machine is a pain in the butt to use while a compile is going on in the background.
...


What's so stupid about the design?

Memory interface, mostly.
Low-quality peripherals, secondly.


Also, you seem to think that performance scales linearly with clockspeed or something?

If I thought that were true, I wouldn't waste money on high-performance disk drives (SCSI/RAID), fast memory busses (800 MHz on my i875 motherboard), high-performance video cards, etc., etc. I'd just buy one of those cheap PCs with a fast processor and let it go at that. ...


Because your dual PII 300 is half as fast as a 2 GHz system, the 2 GHz system is worse?

Absolutely. As I pointed out, my 2.6Ghz system is much faster than the 2.0 GHz system. It ain't that 600MHz making the difference. It's the better system design (especially the memory bus).


It doesn't work that way. Not by a long shot. As you said yourself, the CPU is only one small factor. The CPU is the thing that scaled beyond a factor 2. But what about memory, chipsets, PCI buses etc?

Is that not the point I was making?


Eg if they both use 100 MHz SDRAM modules, I don't find it strange at all that the 2 GHz system would be barely faster with memory-intensive tasks. What choice does it have?

And therein lies the problem. Dual-CPU systems are more expensive because they use better designs. It doesn't make any economic sense to design a dual CPU system with a slow chipset, a slow memory interface, with slow peripherals. When my PII system uses a 33MHz memory bus and the 2.0GHz PIV system uses a 133 MHz bus, you can't expect a 10x performance improvement. When the PII system uses fast&wide SCSI and the PIV system uses cheap IDE drives (probably 66MHz), you don't expect a performance boost. etc., etc. It's amazing the disparity between the PII and the PIV is as great as it is.

Now you throw in a dual-CPU PII system into the works, and the difference between the PII and the PIV diminishes even more. True, no single program is going to be twice as fast on the PII, but overall I can get twice as much work done in the same amount of time when doing compiles and such.

...


I haven't actually heard anyone mention any decent benefits of 64-bit machines at all.

They can address more memory. Pure and simple.



As for multi-CPU, well, we just get the obvious story that if your app is parallelizable, throwing more threads/CPUs at it, will make it faster. But then we can also throw the usual stories at it that you cannot scale CPUs endlessly (this has been proven by people before, no need for me to reiterate all that), and that parallelizable applications are scarce.

I agree 100%. In fact, I believe I mentioned in my original post here that two CPUs provide a fair amount of benefit while four CPUs for personal use is reaching the point of diminishing returns. For servers, 16 x86-class CPUs seems to be the point of diminishing returns. For loosely coupled servers (e.g., web and database servers), the limit is much higher, but clearly the more CPUs you add, the more specialized the application becomes in order to take advantage of that. No one is debating this. The debate is whether or not dual CPU systems are worthwhile and whether a quad Opteron is worth having.


A discussion that has been held many times before. Perhaps you haven't been reading up on the theory in the area?

Well, I *have* taught courses on the subject. I *have* taken a couple of graduate level courses on the subject. And I *have* owned several dual-CPU systems over the years. And rarely have I written any "parallel" code for these machines.


So the conclusion is that we will need to continue to make faster pipelines, if we want to continue to increase performance across the board.

Actually, I read in the LA Times last week that Intel has pretty much giving up on pushing the PIV forward because of heat and power concerns. Most people are arguing that the crazy pipelining scheme they're using is what's tripping them up. So, they're concentrating on putting multiple CPUs on the die rather than trying to speed up the PIV core. Oh well. It had to happen sooner or later.



It's not an assumption. If I look at the people I work with, I see the same patterns. If I talk to other engineers, I again notice the same patterns.

You talk to me and you don't see the same pattern. ...


...
Cheers,
Randy Hyde
Posted on 2004-05-18 23:09:37 by rhyde
...
I gave my technical arguments, and you'll just have to work with those.
Posted on 2004-05-19 07:11:03 by Scali
Win2k sp4 treats the hyperthreading hardware as 2 processors and the main performance problems are working out how to turn off the most junk in win2k


This is exactly the problem. Hyperthreading is NOT 2 processors. It's one processor which is shared between two threads. You only have a single set of functional units, not two. Therefore a different kind of multithreading strategy is required. Windows XP is the only one specifically supporting Hyperthreading as far as I know.

Intel have already made noises about the limitations of the current PIV core in heat terms


Yes, but the 'noises' were mostly about the new 90 nm factory not performing to their expectations. They will release an updated Prescott, which will run cooler and require less power. As the 90 nm process continues to mature, the processors will continue to improve.
Since the Pentium-M is nowhere near the performance of the latest Prescotts, there is no way to predict how well it will scale to such performance. Intel never said they'd move to Pentium-M specifically. They merely said that the P4 as we know it will be replaced with dual-core CPUs. These could just aswell be dual-core P4s. They didn't say. They could also be an entirely new core.

the Itanium will slowly fade away because of its cost and unimpressive performance. Its main failing was its poor performance on x86 code


It's rather silly to call the Itanium a failure because of its x86 performance. Its native performance is right up there with the best of them, and it was never aimed at x86 primarily. Also, the x86 performance (in Windows) is now quite good with the JIT-like x86 VM that is found in the new servicepack. Not bad for a CPU which doesn't aim primarily at running legacy x86 code.
But it's mainly aimed at large servers and workstations, which first of all need the grunt, and being able to run x86 apps at decent speed is of secondary interest.
The AMD CPUs are the opposite. They mainly run legacy code well, but the pure grunt in 64 bit mode is not as impressive.

...I currently have a 1533 MHz machine, and if an Itanium can give me the same performance (which it should, with Windows it should now perform as a Xeon CPU of about the native clockspeed of the Itanium), I would be happy. I don't need more performance at this time. But I know that eventually, the 64 bit performance will be much better, when I migrate to 64 bit.
So I just want legacy code to run "good enough", and getting the absolute best performance is only important for me on 64 bit apps.

We all know that 64 bit hardware predated x86 but we are on the threshold of 64 bit cheap hardware now so its succession is inevitable. It will probably take some years to get up and going but so did 32 bit.


Yes, since it takes years anyway, you should make the right move, I think.
Also, if Itanium were mainstream, it would also be cheaper. The G5 is a reasonably cheap 64 bit CPU aswell. So it's not like AMD is the only possible affordable 64-bit CPU. They just happened to release theirs before Intel did.
Posted on 2004-05-19 07:40:35 by Scali
Afternoon, All.

Yikes! What a heated debate this is:grin: .

It took two cigarettes for me to remove subtle personal jabs at other members. So for my own healths sake, please calm down a bit and stick to the subject matter:alright: .

So far the only benefit of a 64bit system is for addressing more memory.
"So friggin' what?", said I.

Any application I currently run never has memory-addressing problems. What would I need 64bit for?

I've got a 2.4gig P4 with 512megs-o'-ram running WinXP prof.
Whenever I have long compiles (i.e. compiling a Q3 map into a bsp file for MOH:AA) I just ctrl+alt+del, rightclick the compilers' process in the Task Manager, and set it to BelowNormal thread priority.
The process (i.e. compiler) still chugs away happily and it allows me to keep using any other application (i.e. the MoHRadient map editor) like normal. No noticeable slowdown in performance of any other running application was seen (from the users perspective).
Naturally, if I did a bit of intensive work in another application (i.e. grabbed an object in MoHRadient and continuously moved it about onscreen) the other process (i.e. compiler) would take quite a bit more time to complete its work.
However in most cases the applications used are running idle almost the entire time they're used. They only dig at cpu time when you do something, and clicking on menus or scrolling a scrollbar just aren't cpu-intensive enough to affect performance.

So....
Anyone have any ideas about what a 64bit system would give us?

Cheers,
Scronty
Posted on 2004-05-19 08:39:46 by Scronty
Scali, ease down a bit? ^_^

I think for my personal use (and definitely for 'normal people'), HT would be better than SMP, from a economic view. 'normal people' dont need 64bit or multi-ghz or SMP for their office and internet use (apart from flash animations, a pmmx-200 64meg NT4 runs everything fine, including office2000 with a startup time less than 3 seconds).

My own personal use is mainly single-threaded. If I have a compile that takes a long time, I can go to the kitchen and fetch a glass of water, or perhaps to the bathroom. If I do movie encoding, it happens overnight anyway. I don't do 3D rendering, and the amount of parallizable things is small.

A SMP machine would certainly be better, as stuttering *will* happen on a HT machine when the execution units are maxed out (and I guess if 2k treats a HT machine a regular dual-CPU machine with no difference in thread scheduling, it won't be too optimal... but I haven't seen any benchmarks.) For my use, SMP would be a luxury though, and would (in general) only be noticable on the occasions where I backup (with WinRAR) my sourcecode while I'm browsing the net and stuff. So, a single faster CPU is nicer than two slower CPUs.

If I ran a lot of parallelizable stuff, I would rather have two somewhat slower CPUs, than a single with HT, though. Of course two fast CPUs with HT would be the best, but that's not going to happen ;)

Then of course there's the concern of getting a decent motherboard, decent chipset, and decent memory.

But the disk system... what's the big benefit of SCSI these days? ATA133 clearly only reaches the 133mb/s in bursts, and only for very short periods of time - they can still do pretty well sustained, though. Can a single SCSI disk really reach "insanely high" transfer rates, or are the performance benefits other things like much shorter seektime (better than 9ms for an average IDE disk), or perhaps less CPU usage (by smarter interface to the CPU)? Unless you have some very smart integrated controller, you're never going to reach more than some ~130mb/s on a regular PC anyway - since the PCI bust limit is 133mb/s (for 32bit PCI32 - I know there's other PCI standards, but that would usually mean pretty expensive server board :).)

As for the whole 64bit deal, I think it's completely superfluous for normal desktops - ie, office, outlook, IE. A 64bit instruction set isn't that useful for 'normal' applications either, just how often do you need it (...for stuff where performance matters)? And even if you can use SIMD stuff, not everything can (or will) be optimized for that.

Increased memory space is sorta nice, but not that important for the majority of people either. Ok, one application can open multiple huuuge files with memory-mapping, that's a bonus for lazy programmers. And for databases and video editing, it can be an improvement too. But for a lot of other stuff, a 4GB address space is just fine... consider a terminal server. You can stuff in 36gig of ram with PAE mode, and if the x86 is built with NUMA architecture this can even happen without big memory bus problems - and each terminal client won't need even a gig of ram.

I'm a bit annoyed that AMD released their hybrid 32/64 bit stuff. It will force us to stick with the aging x86 technology even longer... consider if we had moved to a pure architecture (if we cared). The core stuff (os + support programs) would be ported, even if IE, outlook and office would run quite fine in emulation mode. The CPUs should be plenty fast enough to handle legacy apps... and anything that matters, which should be the only reason to move to 64bit, would of course be recompiled and take full advatange of the system. But now we're stuck with 32bit x86 code for even longer, and the 64bit part of the AMD-64 *probably* (haven't seen benchmarks) isn't as good as if it had been a pure 64bit breed.

So, 64bit for the masses? Why bother.

Scronty, thanks for editing out crap :)
Posted on 2004-05-19 09:05:32 by f0dder
...

As for SCSI disks... Often they are built on the same mechanics as IDE disks these days. Only the circuitboard is different.
Posted on 2004-05-19 09:24:41 by Scali
:rolleyes:
Posted on 2004-05-19 09:26:18 by f0dder
What I find funny is the illusion that the past holds a person or groups of people from accomplishing some goal. Please, someone explain exactly how the past holds you personally back from doing something? If your goal is to take over the world then you might want to control the past (or the perception of it), but for your individual goals, how does it effect you?
Posted on 2004-05-19 09:27:25 by bitRAKE