It seems as if anyone who had a role in developing modern day systems are dieing. Conspiracy, I sure damn hope not. I think you've watched "Antitrust" a few times too many.;-)
No disrespect to the platform, which even today has yet to be surpassed by PCs in some ways, but you can't exactly go to Best Buy and pick up the latest 68070-powered Amiga PC with optional firewire video toaster add-on.
"I have twenty years experience of UNIX, ten years of Linux. I use Visual Studio and C# out of choice." Why? I'm not disagreeing (the C# IDE is very nice. A good job, and from Microsoft no less!) but I was wondering if you would give specific reasons for your preference to the Microsoft platform if they don't have anything to do with market share.
"You can show a physicist Java and they will still use FORTRAN." One reason for that is because Fortran is simply better for doing advanced mathematics, is FAR faster, is better known in the sciences, and is more mature. I have three relatives that work for NASA (one just on the side for university research, two full-time) and all prefer Fortran. I mentioned C and one of them, admittedly a person that doesn't like changing anything, said that he had tried C and found that it had inferior math libraries. I didn't even mention Java because of speed reasons. When you are calculating the effects of gravity fields from irregular objects of nonuniform densities on spinning objects of nonuniform densities which are maintaining an irregular orbit, all on an imbedded 8088, speed is very important.:)
And this doesn't even touch on the nice sharing and permissions options MS gives us. You mean ACLs? Yes, Windows has a nice set of file permissions--classically one of its advantages over Linux. Linux, however, now has an even more robust set of ACLs which come with GRSecurity, and let's not forget POSIX ACL's which are almost finished. Linux still has all of its security advantages over NT though, such as not using IIS, Outlook*.*, IE, Commerce Server, MS SQL, et al, all of which have had some big nasties recently. True, so have some Linux/Unix daemons, but far less frequently and you have to wait about half an hout to two days for a fix rather than three weeks to a 18 months on into infinity for a patch from Microsoft.
NT does have advantages, but don't EVEN bring up security if you are trying to defend NT. That's a sure-fire way to discredit the platform.
"VMS is not similar to DOS on steroids; maybe DCL looks like a DOS interpreter to you, but the underlying operating system is vastly different from that toy program loader called DOS. Calling them similar is just wrong." That is what I was referring to is the CLI. Regarding the underlying architecture being dissimilar to DOS: My post illustrated that itself. I know. Just the fact that VMS is, as I said, a multiuser OS makes it vastly different underneath. Just as many people see little difference between Windows ME and Windows NT and talk about interface similarities, so too was I talking about interface similarities. The difference being I know the differences are more than skin deep.
"It's C compiler sucks" You must be joking. DEC is famous for having some of the best compiler gurus; historically, their compilers have always been among the best, both in speed and code generation. Tartan was the only company I recall that could beat DEC on a VAX, and no one's yet matched them for code generation on Alpha. That VMS would somehow ship with inferior compilers doesn't make sense."I wasn't referring to the speed of code generated as much as the irritation of using it. Granted, I did not check what version of the C compiler I was using, but it was lacking in some features. It's fflush(); worked erratically (though that has more to do with the libs than the compile I bet) and it didn't even support "//" comments. Granted, "//" was a C++ (not C) standard until C99, but nearly every other compiler I have used supports it perfectly. Looking back these may seem to be very minor but did not leave a good impression about the software. Perhaps saying that the compiler sucks was a bit of an overstatement.:)
"It never overwrites old files..." Many like this feature: by putting those hooks in at the filesystem level, all commands automatically inherit file versioning. Yes some people really like this feature--I am sure it has saved many people from a horrible death, but many people including myself actually find it irritating. This would probably not be the case were I more used to it, but I have become accustomed to my own ways of versioning and do not particularly like the extra step. Additionally, the file names generated for versioning are often difficult to associate unless one keeps close mental track of their saves. My foo() function isn't working now, but it was working three days ago. Was that in bar.c;27 or bar.c;39? Yes, you can still version yourself, for example simply making copies of files at important points in time and naming them appropriately, but having a default system tends to discourage people from using that, just as a PC coming with Windows 98 discourages use of something better like Win2K or an alternative OS. Human laziness? Probably.
Nobody who can read a manual suffers from a slow memory subsystem on their VMS box.I can't read. Sorry.:)
I'm quite willing to be corrected. But, even older versions of VMS say otherwise about your comments.So am I, and no problem here. You clearly know more about VMS than I, and I appreciate your input.
VMS didn't go anywhere. Windows NT is based so closely on VMS that some have called it a new version of VMS with a GUI tacked on. David N. Cutler, the chief software architect of NT, worked for DEC in the 70's. He had designed VMS and worked on releasing newer versions. Cutler became bored doing this so DEC gave him several hundred engineers and computer scientists to work on a next generation CPU and OS. In 1988, DEC laid many on David N. Cutler's team and nuked both projects. He was fairly ticked off and left Digital only to be hired by Microsoft, bringing quite a few former DEC guys with him. Cutler designed NT very similarly to how he designed VMS and Microsoft actually licensed several parts of VMS from DEC in a cross-licensing agreement in which DEC got the chance to use some of the Windows API in pure VMS. (How useful this was to DEC is questionable...)
So despite Microsoft marketing that NT is a cutting-end OS and even naming it "New technology," like Unix it is still based 1970's ideas and code.
As for pure VMS, my school uses it for both the C and the Pascal classes. DirecTV uses it for their billing system called STMS. (How I found this out has plenty to do with/., ironically) }:>
I have found that it is very similar to DOS on steroids. It uses very similar commands, uses forward slashes `/' for parameters, uses extentions for file names (the same ones as DOS;.exe,.obj, etc.) but unlike DOS is very good at having a ton of simultaneous users. Some differences: Its C compiler sucks, it never overwrites old files but instead makes files of a similar name (foo.c, foo.c;2, foo.c;3 etc.), its memory manager is famous for being fairly slow (though DOS has no memory management to speak of), and it makes a good server OS. Unfortunately if you want to run it, you have the choice between VAX and Alpha, neither of which are particularly common machines. You can run quite a bit of Unix software on these things just fine if you compile it letting the make script know that the system is VMS.
Somebody out there actually realizes that the current music business model will eventually fail. How refreshing it is to see intelligence in corporate America once more.
Making a person "guilty" would probably be more of a "crock" though. I would bet that Sigma was fully aware that they were using GPL code, including management, and that they thought they would simply not be caught because the code was not open source. I doubt that it was just one individual that happens to have based their encoder on an open source project. "Hey Bob, how's that encoder that ONLY YOU are working on?" "Oh, I uh... Got it finished last night. Yep, I started coding a transcoder for MPEG4, one of the most complex video compression formats ever created, just a few days ago and now have it finished." "Oh, okay cool. How about Lunch?"
Thankyou, that was a much more informative post than your previous one, and probably more informative than mine as well.:) Regarding the comment about infinite cache, your message seemed to imply that latency was all that mattered, and that an Athlon with a huge (say, 512MB) cache would be slower than a P4 with it's 8K of faster cache. Seeing as how hust about everything would be run entirely from L1 cache on the Athlon, that seemed rather silly. Perhaps I misinterpreted what you were trying to say. Indeed, the L1 cache of the Pentium IV is extremely fast. The benchmarks of handling data sizes of 8K are astonishing, but size does matter as has been seen by increasing the L2 cache of the exact same Pentium IV. As I understand it, Intel chose an 8K cache both to reduce transistor count and to reduce L1 cache latency, which worked, but is of dubious real value. (it is difficult to tell for sure unless Intel makes a P4 with a larger, slower cache, which I doubt)
The purpose of my original post wasn't really to focus on cache size vs. speed, but to highlight questionable design decisions made with the P4. There are other problems (what I consider problems) with the core as well, which I didn't highlight. For example, why is bit shifting so incredibly slow on the Pentium IV? It's faster on just about any other Intel or AMD processor and has long been recommended as an optimization for doing multiplication/division of numbers whose values neatly fell on bit boundries (256, 65,536, etc.) and now this optimization can actually make code/slower/ on the P4? Eh? Looking at the execution time of various instructions, the P4 has taken quite a few other steps backwards as well.
I remember when people were criticizing AMD for calling the Athlon a 7th generation processor. The rationale was that the P2 was about 30% faster per clock than the Pentium Classic, and the Pentium was about 30% percent faster (this all depends on the code of course) than the 486, yet the Athlon was not 30% faster per clock than the Pentium 2 or K6. I wonder where all of these people are now that Intel's "7th generation part" is not only not 30% faster, but is actually 30% slower in most tasks, on average. Strange world we live in.
Obviously you flunked your freshman-level computer architecture course. The P4 8K L1's 2-cycle load-use latency is 50% better than Athlon 128k L1's 3-cycle load-use latency (not even accounting for P4's clock speed advantage).Obviously you are imagining things, as I never said that was not the case. Latency is important, but it doesn't matter if the cache size isn't large enough to fit enough code in to enjoy the low latency. The difference in hit rate between 8k and 128k is only about 5% meaning that it is substantially faster to go with the small/fast cache than the big/slow cache. Really? That's interesting, and here's me wondering why both AMD and, other than in the P4, Intel have wasted so much money adding more cache memory.
Because you seem to be such an expert, so why don't you go ahead and list a few common programs for me that have a working set of less than 8K--the size that will fit into the tiny L1 cache. Can't find any? Gee, I guess that makes the size of the cache pretty important then. When a program's working set has to be swapped in and out between L1 and L2 cache, suddenly that latency doesn't much matter. Of course, you may feel free to prove to me that the P4 can run addition loops faster. Those will fit into about 8k.
Do the math - even an infinitely large 3-cycle load-use cache is slower than an 8k 2-cycle load-use cache. Who was it again flunked their freshman computer architecture course? You're saying that if the Athlon had 512MB of L1 cache that the system would be slower than the P4 and it's 8K of lower latency cache? What math is it that I should do? Do you know what the working set of a program is? Having a tiny amount of cache is analogous to having a tiny amount of RAM. Put 32MB of low-latency RAM in your system. Overclock some DDR SDRAM to 200MHz (AKA "400MHz" by people that don't understand clock speeds) and set it to CAS2. Tell me how your system performs. Just as your system will have to swap just about all running code to disk, the Pentium IV will not be able to contain the core loops of the various running programs in L1 cache. The vast majority will have to be dropped to L2, which is significantly slower and higher latency, kinda defeating the purpose of that 8k of fast memory, no? Working sets that cannot be fit into the P4's 256k or 512k or L2 will then be relegated to main memory and moved to L2 then L1 when the data is executed, and anything that won't fit in main memory (very rarely which includes the working set of a program) will be swapped to disk if the platform supports virtualizing memory.
In closing, your comment was surprisingly brash and conceited, not to mention rude and totally innacurate. Thankyou.
Besides, AMD has always been the value chip company. You can't expect them to keep up with Intel forever.
AMD has had a superior (in design) processor architecture to Intel since the K6 was released (though the K6 had mediocre FPU performance, the design was still more elegant--ask any x86 assembly programmer). The Athlon has given the P2, P3, AND P4 a run for its money, and early benchmarks of the hammer would seem to indicate that the expensive Itanium 2, which almost nobody actually uses, is going to be outrun as well. The Pentium IV's really looong pipeline does allow the P4 to run at higher clockspeeds, but the branch prediction you mentioned is instant death. Branch mispredictions happen VERY frequently in any CPU (note the K6 had the most sophisticated branch prediction unit up until the "XP" series of Athlons) but with the Pentium IV, a single branch prediction requires up to 20 full clock cycles of work to be discarded. The Pentium IV has other questionable design desisions that hurt performance as well. It has 8K of L1 cache, the same amount found in the ancient 486 processor, whereas the Athlon has that amount squared and doubled (128K). Current P4's have more L2 cache, but L2 cache is less important and slower. (Note though that the P4's L2 cache is particularly fast L2 cache) The P4 has buffers to remember a series of decoded x86 instructions so that it does not have to decode them again--these are almost required because of the terribly long pipeline--but it doesn't have enough to speed things up in server environments. Most servers execute a wide variety of instructions such that the buffered instructions get very little use before being replaced by new instructions. This is even more a problem on systems that run many different applications at once, but this problem can be demonstrated just with DB servers (which use plenty of instructions) as the P4 tends to not scale as well as the Athlon MP when a second or third task is added (such as mail serving, web serving, etc.)
One dissapointment that I had with the Athlon is that AMD never used the excellent EV6 bus to its fullest. Athlons are superior in multiprocessor capabilities because different processors needn't share access to the memory bus. On Intel SMP setups, even on P4 Xeons (Which, IMO, are inferior to P3 Tualatin chips by the same company) when one CPU accesses main memory, it locks main memory for the other CPUs. All other CPUs have to sit and twiddle their transistors while the main memory is on use by only one CPU. On AMD SMP setups, ALL processors can simultaneous access memory, merely sharing the bandwidth simultaneously. So, if one CPU is only using 100MB of memory bandwidth, the rest can be used by other CPUs at that time. Unfortunately, this doesn't really matter much with only two CPUs, which is the largest AMD configuration you can get. You can, of course, see it in action with 8+ CPUs on EV6 Alpha setups (AMD licensed the bus from DEC's Alpha team) but Alpha setups are expensive as hell and are a dying breed. If AMD had created a quad or 8-way setup, we would see the true power of a good design.
Fortunately, the Hammer has an even better design (one made by AMD no less) on an even better CPU. I fully expect the Hammer series to wipe the floor with all Xeons and possibly the Itanium 2 because of its design. An integrated memory controller that will tremendously drop memory latency, twice as many general-purpose registers of twice the size (Much less pushing and popping, for those that know some assembly) and, unlike the big vendor 64-bit processors, the ability to split half of the general purpose registers into chunks of 16 and 32 bits when huge numbers (2^64) are not needed. (On an Alpha/SPARC/R12000, if you want to store the number "42" you must use all of a register that can hold values up to 18,446,744,073,709,551,615. A bit wasteful)
I used SourceSafe and hated it for exactly the opposite reason--Occasionally developers forgot to un-checkout files and SourceSafe wasn't smart enough to realize that if their computer has been off for 8 hours, they may not be working on that file anymore. There didn't seem to be a way to unlock it even with admin rights.
The GCC programmers didn't break ABI compatibility to anger you or to encourage Sun to make Java a real standard or open-source it; they did so because there were some bugs in the GCC C++ ABI that made it incompatible with *the standard*, so the choices were:
Fix it now and piss a few people off, fix it later and piss a ton of people off, or never fix it and be a nonstandard compiler. GCC: A nonstandard compiler. Um, no. Compilers, particularly C++ compilers (GCC broke ONLY the C++ ABI) are ENORMOUSLY complex pieces of software and that the things even work are miracles in and of themselves. This one had bug. It happens. Try to tell me that Microsoft's compiler doesn't have bugs, or that ANY other compiler does not.
You see, if you would have done a little homework rather than labelling that which you know little about as FUD, you would have known this. (Not that I am not guilty of the same thing every so often:)
It's easy to think, who would ever know? Comparing binary compiles is a good way of testing, but it's not 100% proof. It's damn close, but would a judge know that?
I looked at some of the PDFs and there were parts that were written in pure assembler that no compiler would produce. That, to me, is 100% proof.
Myth/rumor: The Athlon XP is a furnace of unimaginable heat! I'm getting a Pentium IV! Even though they are slower and more expensive, at least they won't dim the lights then melt them!
The fastest Athlon XP chips dissipate less than 5% more heat than the fastest Pentium IV chips. They can, however, handle more heat before cooking.
Myth/rumor: Tom's Hardware guide is "more objectvice" or even "Tom's Hardware guide is reliable" I can't believe I read this, even in a Slashdot comment. Tom's Hardware Guide is infamous among forums such as those at StorageReview.com and among people that actually know what they are talking about for being little more than a hardware review tabloid. Read the reviews! They come to illogical conclusions and sensationalize most of their reviews. Read the Athlon review in question: This is AMD's admission that the previous performance scale was set too high, especially when it came to the higher clock speeds. Umm... Could it be that because the CPU is advancing where the other components such as memory and FSB are not, that it is possible that AMD added another 66MHz to make sure the rating system was still accurate? It isn't like system performance scales linearly with CPU speed when everything else sits still. Whoever thinks that Tom's Hardware is a good place to get hardware reviews doesn't have a clue about hardware! Read Tom's glorious review of the KT266a vs the Nforce where despite there being less than a 5% difference between the chipsets and despite the Nforce outperforming every one of the many KT266a that outnumber it greatly in some tests, their "conclusion" was Conclusion: KT266A Trounces nForce 420D - Soltek is Front-runner Tom's has had some good reviews, and most of the reviews BY TOM HIMSELF are pretty good, but most of the reviews are from his editors, and the proof is in the reviews--they are making Tom's Hardware more of a tabloid than a legit hardware review site, riding on the reputation that Tom made for the site years ago. I know, I was once an avid Tom's reader and am disgusted how the once clear and thoughtful reviews have turned into manic drivel. If you want reviews that are actually well thought out, intelligent, and have sane conclusions based on mere facts, try Ace's Hardware, Ars Technica, and Anandtech. Ace's Hardware reviews are clearly the best and most researched, but they are few and far between. Want an excellent review of current and future memory technologies written with the help of actual engineers? Read Ace's Hardware. Ars rarely has hardware reviews, but when they do the reviews are good. Anandtech is a good all-around major review site that as far as I can tell has never been biased, but is a little bit too PC for me. (that's Politically Correct, not the other one)
Is Tom's biased? Read the reviews! They aren't biased in a classic sense as far as I can tell, that is, they don't "always favor Intel" or "Always favor AMD"; rather they are often biased against one or the other. They will post stories that are clearly opinionated bullshit from ignorant tech writers that tend to have a bias against one or ther other. This is a mystery to me as they surely piss off both AMD and Intel all the time, and don't make any friends in the process. Overall, I wouldn't say that bias is a big problem at Tom's Hardware as much as stupid technical writers that don't know what they are talking about is a problem. Want more examples? Point me to a review at Tom's and I'll tell you what's wrong with it (if there is anything wrong with that particular one)
At Tom's--read the reviews by Tom, but everyone else is not trustworthy.
Myth/rumor: When you hold a seashell up to your ear, you can hear the sea. Fact: You can hear the same sound reflections by holding a drinking cup up to your ear. It has nothing to do with the ocean. The question is, if you hold a Unix shell up to your ear, can you hear the C?
There's already a review on Ace's Hardware which concludes that the Athlon 2600+ has again leapfrogged the fastest Intel CPU. Of course, when Intel releases the 2.8GHz P4 next Monday, it will yet again leap over AMD.
The integrated memory controller of the Hammer series chips can be disabled and replaced with a motherboard-based memory controller. Additionally, the core of the processors were designed to make it fairly easy to swap integrated memory controllers, but "easy" is a much looser term when describing modifying a multimillion transistor multilayer CPU core. Either way, it will not be a problem.
Slashdot Mirror
It seems as if anyone who had a role in developing modern day systems are dieing. Conspiracy, I sure damn hope not. ;-)
I think you've watched "Antitrust" a few times too many.
Er... Isn't the Amiga already dead?
No disrespect to the platform, which even today has yet to be surpassed by PCs in some ways, but you can't exactly go to Best Buy and pick up the latest 68070-powered Amiga PC with optional firewire video toaster add-on.
If he can make a Ford Escort look nearly identical to Luke's land speeder, surely the buyer can tweak the interior a bit?
"I have twenty years experience of UNIX, ten years of Linux. I use Visual Studio and C# out of choice."
:)
Why? I'm not disagreeing (the C# IDE is very nice. A good job, and from Microsoft no less!) but I was wondering if you would give specific reasons for your preference to the Microsoft platform if they don't have anything to do with market share.
"You can show a physicist Java and they will still use FORTRAN."
One reason for that is because Fortran is simply better for doing advanced mathematics, is FAR faster, is better known in the sciences, and is more mature. I have three relatives that work for NASA (one just on the side for university research, two full-time) and all prefer Fortran. I mentioned C and one of them, admittedly a person that doesn't like changing anything, said that he had tried C and found that it had inferior math libraries.
I didn't even mention Java because of speed reasons. When you are calculating the effects of gravity fields from irregular objects of nonuniform densities on spinning objects of nonuniform densities which are maintaining an irregular orbit, all on an imbedded 8088, speed is very important.
And this doesn't even touch on the nice sharing and permissions options MS gives us.
You mean ACLs? Yes, Windows has a nice set of file permissions--classically one of its advantages over Linux.
Linux, however, now has an even more robust set of ACLs which come with GRSecurity, and let's not forget POSIX ACL's which are almost finished.
Linux still has all of its security advantages over NT though, such as not using IIS, Outlook*.*, IE, Commerce Server, MS SQL, et al, all of which have had some big nasties recently. True, so have some Linux/Unix daemons, but far less frequently and you have to wait about half an hout to two days for a fix rather than three weeks to a 18 months on into infinity for a patch from Microsoft.
NT does have advantages, but don't EVEN bring up security if you are trying to defend NT. That's a sure-fire way to discredit the platform.
"VMS is not similar to DOS on steroids; maybe DCL looks like a DOS interpreter to you, but the underlying operating system is vastly different from that toy program loader called DOS. Calling them similar is just wrong."
:)
:)
That is what I was referring to is the CLI. Regarding the underlying architecture being dissimilar to DOS: My post illustrated that itself. I know. Just the fact that VMS is, as I said, a multiuser OS makes it vastly different underneath.
Just as many people see little difference between Windows ME and Windows NT and talk about interface similarities, so too was I talking about interface similarities. The difference being I know the differences are more than skin deep.
"It's C compiler sucks" You must be joking. DEC is famous for having some of the best compiler gurus; historically, their compilers have always been among the best, both in speed and code generation. Tartan was the only company I recall that could beat DEC on a VAX, and no one's yet matched them for code generation on Alpha. That VMS would somehow ship with inferior compilers doesn't make sense."I wasn't referring to the speed of code generated as much as the irritation of using it. Granted, I did not check what version of the C compiler I was using, but it was lacking in some features. It's fflush(); worked erratically (though that has more to do with the libs than the compile I bet) and it didn't even support "//" comments. Granted, "//" was a C++ (not C) standard until C99, but nearly every other compiler I have used supports it perfectly. Looking back these may seem to be very minor but did not leave a good impression about the software. Perhaps saying that the compiler sucks was a bit of an overstatement.
"It never overwrites old files..." Many like this feature: by putting those hooks in at the filesystem level, all commands automatically inherit file versioning. Yes some people really like this feature--I am sure it has saved many people from a horrible death, but many people including myself actually find it irritating. This would probably not be the case were I more used to it, but I have become accustomed to my own ways of versioning and do not particularly like the extra step. Additionally, the file names generated for versioning are often difficult to associate unless one keeps close mental track of their saves. My foo() function isn't working now, but it was working three days ago. Was that in bar.c;27 or bar.c;39?
Yes, you can still version yourself, for example simply making copies of files at important points in time and naming them appropriately, but having a default system tends to discourage people from using that, just as a PC coming with Windows 98 discourages use of something better like Win2K or an alternative OS. Human laziness? Probably.
Nobody who can read a manual suffers from a slow memory subsystem on their VMS box.I can't read. Sorry.
I'm quite willing to be corrected. But, even older versions of VMS say otherwise about your comments.So am I, and no problem here. You clearly know more about VMS than I, and I appreciate your input.
VMS didn't go anywhere. Windows NT is based so closely on VMS that some have called it a new version of VMS with a GUI tacked on.
/., ironically) }:>
.exe, .obj, etc.) but unlike DOS is very good at having a ton of simultaneous users.
David N. Cutler, the chief software architect of NT, worked for DEC in the 70's. He had designed VMS and worked on releasing newer versions. Cutler became bored doing this so DEC gave him several hundred engineers and computer scientists to work on a next generation CPU and OS.
In 1988, DEC laid many on David N. Cutler's team and nuked both projects. He was fairly ticked off and left Digital only to be hired by Microsoft, bringing quite a few former DEC guys with him.
Cutler designed NT very similarly to how he designed VMS and Microsoft actually licensed several parts of VMS from DEC in a cross-licensing agreement in which DEC got the chance to use some of the Windows API in pure VMS. (How useful this was to DEC is questionable...)
So despite Microsoft marketing that NT is a cutting-end OS and even naming it "New technology," like Unix it is still based 1970's ideas and code.
As for pure VMS, my school uses it for both the C and the Pascal classes.
DirecTV uses it for their billing system called STMS. (How I found this out has plenty to do with
I have found that it is very similar to DOS on steroids. It uses very similar commands, uses forward slashes `/' for parameters, uses extentions for file names (the same ones as DOS;
Some differences: Its C compiler sucks, it never overwrites old files but instead makes files of a similar name (foo.c, foo.c;2, foo.c;3 etc.), its memory manager is famous for being fairly slow (though DOS has no memory management to speak of), and it makes a good server OS. Unfortunately if you want to run it, you have the choice between VAX and Alpha, neither of which are particularly common machines.
You can run quite a bit of Unix software on these things just fine if you compile it letting the make script know that the system is VMS.
Seagate ATA drives aren't the best, but their SCSI drives are. Period. They are the fastest, they are the most reliable, they are the most trusted.
FYi this information has been on the StorageReview.com forums for about a week. There is a small discussion there.
Damnit, now I have to change phone companies -again-. Life is so much simpler when evil companies stay evil.
"Who knows, we may make that mark on your driver's license obsolete after all."
I thought it was pigs that would be doing the... Oh.
It's very difficult to be an optimist with information like that.
Somebody out there actually realizes that the current music business model will eventually fail. How refreshing it is to see intelligence in corporate America once more.
Making a person "guilty" would probably be more of a "crock" though. I would bet that Sigma was fully aware that they were using GPL code, including management, and that they thought they would simply not be caught because the code was not open source.
I doubt that it was just one individual that happens to have based their encoder on an open source project. "Hey Bob, how's that encoder that ONLY YOU are working on?"
"Oh, I uh... Got it finished last night. Yep, I started coding a transcoder for MPEG4, one of the most complex video compression formats ever created, just a few days ago and now have it finished."
"Oh, okay cool. How about Lunch?"
No.
Thankyou, that was a much more informative post than your previous one, and probably more informative than mine as well. :)
/slower/ on the P4? Eh?
Regarding the comment about infinite cache, your message seemed to imply that latency was all that mattered, and that an Athlon with a huge (say, 512MB) cache would be slower than a P4 with it's 8K of faster cache. Seeing as how hust about everything would be run entirely from L1 cache on the Athlon, that seemed rather silly. Perhaps I misinterpreted what you were trying to say.
Indeed, the L1 cache of the Pentium IV is extremely fast. The benchmarks of handling data sizes of 8K are astonishing, but size does matter as has been seen by increasing the L2 cache of the exact same Pentium IV.
As I understand it, Intel chose an 8K cache both to reduce transistor count and to reduce L1 cache latency, which worked, but is of dubious real value. (it is difficult to tell for sure unless Intel makes a P4 with a larger, slower cache, which I doubt)
The purpose of my original post wasn't really to focus on cache size vs. speed, but to highlight questionable design decisions made with the P4. There are other problems (what I consider problems) with the core as well, which I didn't highlight. For example, why is bit shifting so incredibly slow on the Pentium IV? It's faster on just about any other Intel or AMD processor and has long been recommended as an optimization for doing multiplication/division of numbers whose values neatly fell on bit boundries (256, 65,536, etc.) and now this optimization can actually make code
Looking at the execution time of various instructions, the P4 has taken quite a few other steps backwards as well.
I remember when people were criticizing AMD for calling the Athlon a 7th generation processor. The rationale was that the P2 was about 30% faster per clock than the Pentium Classic, and the Pentium was about 30% percent faster (this all depends on the code of course) than the 486, yet the Athlon was not 30% faster per clock than the Pentium 2 or K6.
I wonder where all of these people are now that Intel's "7th generation part" is not only not 30% faster, but is actually 30% slower in most tasks, on average.
Strange world we live in.
Obviously you flunked your freshman-level computer architecture course. The P4 8K L1's 2-cycle load-use latency is 50% better than Athlon 128k L1's 3-cycle load-use latency (not even accounting for P4's clock speed advantage).Obviously you are imagining things, as I never said that was not the case. Latency is important, but it doesn't matter if the cache size isn't large enough to fit enough code in to enjoy the low latency.
The difference in hit rate between 8k and 128k is only about 5% meaning that it is substantially faster to go with the small/fast cache than the big/slow cache.
Really? That's interesting, and here's me wondering why both AMD and, other than in the P4, Intel have wasted so much money adding more cache memory.
Because you seem to be such an expert, so why don't you go ahead and list a few common programs for me that have a working set of less than 8K--the size that will fit into the tiny L1 cache. Can't find any? Gee, I guess that makes the size of the cache pretty important then. When a program's working set has to be swapped in and out between L1 and L2 cache, suddenly that latency doesn't much matter. Of course, you may feel free to prove to me that the P4 can run addition loops faster. Those will fit into about 8k.
Do the math - even an infinitely large 3-cycle load-use cache is slower than an 8k 2-cycle load-use cache.
Who was it again flunked their freshman computer architecture course? You're saying that if the Athlon had 512MB of L1 cache that the system would be slower than the P4 and it's 8K of lower latency cache?
What math is it that I should do? Do you know what the working set of a program is?
Having a tiny amount of cache is analogous to having a tiny amount of RAM. Put 32MB of low-latency RAM in your system. Overclock some DDR SDRAM to 200MHz (AKA "400MHz" by people that don't understand clock speeds) and set it to CAS2. Tell me how your system performs. Just as your system will have to swap just about all running code to disk, the Pentium IV will not be able to contain the core loops of the various running programs in L1 cache. The vast majority will have to be dropped to L2, which is significantly slower and higher latency, kinda defeating the purpose of that 8k of fast memory, no?
Working sets that cannot be fit into the P4's 256k or 512k or L2 will then be relegated to main memory and moved to L2 then L1 when the data is executed, and anything that won't fit in main memory (very rarely which includes the working set of a program) will be swapped to disk if the platform supports virtualizing memory.
In closing, your comment was surprisingly brash and conceited, not to mention rude and totally innacurate. Thankyou.
Besides, AMD has always been the value chip company. You can't expect them to keep up with Intel forever.
AMD has had a superior (in design) processor architecture to Intel since the K6 was released (though the K6 had mediocre FPU performance, the design was still more elegant--ask any x86 assembly programmer). The Athlon has given the P2, P3, AND P4 a run for its money, and early benchmarks of the hammer would seem to indicate that the expensive Itanium 2, which almost nobody actually uses, is going to be outrun as well.
The Pentium IV's really looong pipeline does allow the P4 to run at higher clockspeeds, but the branch prediction you mentioned is instant death. Branch mispredictions happen VERY frequently in any CPU (note the K6 had the most sophisticated branch prediction unit up until the "XP" series of Athlons) but with the Pentium IV, a single branch prediction requires up to 20 full clock cycles of work to be discarded.
The Pentium IV has other questionable design desisions that hurt performance as well. It has 8K of L1 cache, the same amount found in the ancient 486 processor, whereas the Athlon has that amount squared and doubled (128K). Current P4's have more L2 cache, but L2 cache is less important and slower. (Note though that the P4's L2 cache is particularly fast L2 cache)
The P4 has buffers to remember a series of decoded x86 instructions so that it does not have to decode them again--these are almost required because of the terribly long pipeline--but it doesn't have enough to speed things up in server environments. Most servers execute a wide variety of instructions such that the buffered instructions get very little use before being replaced by new instructions. This is even more a problem on systems that run many different applications at once, but this problem can be demonstrated just with DB servers (which use plenty of instructions) as the P4 tends to not scale as well as the Athlon MP when a second or third task is added (such as mail serving, web serving, etc.)
One dissapointment that I had with the Athlon is that AMD never used the excellent EV6 bus to its fullest. Athlons are superior in multiprocessor capabilities because different processors needn't share access to the memory bus. On Intel SMP setups, even on P4 Xeons (Which, IMO, are inferior to P3 Tualatin chips by the same company) when one CPU accesses main memory, it locks main memory for the other CPUs. All other CPUs have to sit and twiddle their transistors while the main memory is on use by only one CPU.
On AMD SMP setups, ALL processors can simultaneous access memory, merely sharing the bandwidth simultaneously. So, if one CPU is only using 100MB of memory bandwidth, the rest can be used by other CPUs at that time.
Unfortunately, this doesn't really matter much with only two CPUs, which is the largest AMD configuration you can get. You can, of course, see it in action with 8+ CPUs on EV6 Alpha setups (AMD licensed the bus from DEC's Alpha team) but Alpha setups are expensive as hell and are a dying breed.
If AMD had created a quad or 8-way setup, we would see the true power of a good design.
Fortunately, the Hammer has an even better design (one made by AMD no less) on an even better CPU. I fully expect the Hammer series to wipe the floor with all Xeons and possibly the Itanium 2 because of its design. An integrated memory controller that will tremendously drop memory latency, twice as many general-purpose registers of twice the size (Much less pushing and popping, for those that know some assembly) and, unlike the big vendor 64-bit processors, the ability to split half of the general purpose registers into chunks of 16 and 32 bits when huge numbers (2^64) are not needed. (On an Alpha/SPARC/R12000, if you want to store the number "42" you must use all of a register that can hold values up to 18,446,744,073,709,551,615. A bit wasteful)
I used SourceSafe and hated it for exactly the opposite reason--Occasionally developers forgot to un-checkout files and SourceSafe wasn't smart enough to realize that if their computer has been off for 8 hours, they may not be working on that file anymore. There didn't seem to be a way to unlock it even with admin rights.
I already posted on this topic, but this person deserves upwards moderation.
The GCC programmers didn't break ABI compatibility to anger you or to encourage Sun to make Java a real standard or open-source it; they did so because there were some bugs in the GCC C++ ABI that made it incompatible with *the standard*, so the choices were:
:)
Fix it now and piss a few people off, fix it later and piss a ton of people off, or never fix it and be a nonstandard compiler.
GCC: A nonstandard compiler. Um, no.
Compilers, particularly C++ compilers (GCC broke ONLY the C++ ABI) are ENORMOUSLY complex pieces of software and that the things even work are miracles in and of themselves. This one had bug. It happens. Try to tell me that Microsoft's compiler doesn't have bugs, or that ANY other compiler does not.
You see, if you would have done a little homework rather than labelling that which you know little about as FUD, you would have known this. (Not that I am not guilty of the same thing every so often
It's easy to think, who would ever know? Comparing binary compiles is a good way of testing, but it's not 100% proof. It's damn close, but would a judge know that?
I looked at some of the PDFs and there were parts that were written in pure assembler that no compiler would produce. That, to me, is 100% proof.
Myth/rumor: The Athlon XP is a furnace of unimaginable heat! I'm getting a Pentium IV! Even though they are slower and more expensive, at least they won't dim the lights then melt them!
The fastest Athlon XP chips dissipate less than 5% more heat than the fastest Pentium IV chips. They can, however, handle more heat before cooking.
Myth/rumor: Tom's Hardware guide is "more objectvice" or even "Tom's Hardware guide is reliable"
I can't believe I read this, even in a Slashdot comment.
Tom's Hardware Guide is infamous among forums such as those at StorageReview.com and among people that actually know what they are talking about for being little more than a hardware review tabloid. Read the reviews! They come to illogical conclusions and sensationalize most of their reviews.
Read the Athlon review in question:
This is AMD's admission that the previous performance scale was set too high, especially when it came to the higher clock speeds.
Umm... Could it be that because the CPU is advancing where the other components such as memory and FSB are not, that it is possible that AMD added another 66MHz to make sure the rating system was still accurate? It isn't like system performance scales linearly with CPU speed when everything else sits still. Whoever thinks that Tom's Hardware is a good place to get hardware reviews doesn't have a clue about hardware!
Read Tom's glorious review of the KT266a vs the Nforce where despite there being less than a 5% difference between the chipsets and despite the Nforce outperforming every one of the many KT266a that outnumber it greatly in some tests, their "conclusion" was Conclusion: KT266A Trounces nForce 420D - Soltek is Front-runner
Tom's has had some good reviews, and most of the reviews BY TOM HIMSELF are pretty good, but most of the reviews are from his editors, and the proof is in the reviews--they are making Tom's Hardware more of a tabloid than a legit hardware review site, riding on the reputation that Tom made for the site years ago. I know, I was once an avid Tom's reader and am disgusted how the once clear and thoughtful reviews have turned into manic drivel.
If you want reviews that are actually well thought out, intelligent, and have sane conclusions based on mere facts, try Ace's Hardware, Ars Technica, and Anandtech.
Ace's Hardware reviews are clearly the best and most researched, but they are few and far between. Want an excellent review of current and future memory technologies written with the help of actual engineers? Read Ace's Hardware.
Ars rarely has hardware reviews, but when they do the reviews are good.
Anandtech is a good all-around major review site that as far as I can tell has never been biased, but is a little bit too PC for me. (that's Politically Correct, not the other one)
Is Tom's biased? Read the reviews! They aren't biased in a classic sense as far as I can tell, that is, they don't "always favor Intel" or "Always favor AMD"; rather they are often biased against one or the other. They will post stories that are clearly opinionated bullshit from ignorant tech writers that tend to have a bias against one or ther other. This is a mystery to me as they surely piss off both AMD and Intel all the time, and don't make any friends in the process. Overall, I wouldn't say that bias is a big problem at Tom's Hardware as much as stupid technical writers that don't know what they are talking about is a problem.
Want more examples? Point me to a review at Tom's and I'll tell you what's wrong with it (if there is anything wrong with that particular one)
At Tom's--read the reviews by Tom, but everyone else is not trustworthy.
Myth/rumor:
When you hold a seashell up to your ear, you can hear the sea.
Fact: You can hear the same sound reflections by holding a drinking cup up to your ear. It has nothing to do with the ocean. The question is, if you hold a Unix shell up to your ear, can you hear the C?
There's already a review on Ace's Hardware which concludes that the Athlon 2600+ has again leapfrogged the fastest Intel CPU. Of course, when Intel releases the 2.8GHz P4 next Monday, it will yet again leap over AMD.
Ad infinitum.
The integrated memory controller of the Hammer series chips can be disabled and replaced with a motherboard-based memory controller. Additionally, the core of the processors were designed to make it fairly easy to swap integrated memory controllers, but "easy" is a much looser term when describing modifying a multimillion transistor multilayer CPU core.
Either way, it will not be a problem.
Indeed. If you check the e-mail address, they are also submitters _to_ Slashdot.