Re:Hmmm. Complexity vs. Cash
on
RSA-576 Factored
·
· Score: 2, Interesting
Factoring composite is probably somewhat easier in the sense that it doesn't require more hardware/brute force computational power, however, its probably harder in the sense that you need to be very famillar with the very latest in factoring algorithms and essentially be skilled and willing enough to implement the very leading edge known algorithms.
In other words, factoring RC5-72 requires Moore's law, plus a massively growing audience of people willing to participate. But even with the most optimistic projections, RC5-72 will not fall for decades. Factoring something like RSA-574 requires that you be up on the latest in computational mathematics as it relates to number theory. If you think you can bone up on the latest in factoring techniques in less than 10 years, then you probably have a better shot at the RSA prizes.
My first reaction is one of disbelief. You can claim a draw in a (formerly) lost position, but you don't out of "respect" for the opponent? Why not resign right away?
I can't believe that guy is a good chess player himself. Only weak players do things like this, allow someone to move another piece after they took one in their hands to move it, etc...
You understand very little about chess. Remember that players, computers or otherwise, put in an enormous effort to play at such high levels. The players are, in a sense creating a work of art on the board. For these players or program authors who have a certain respect for the *art* of the game, winning by some technicality, or other rule that ruins the *art* of what they are doing is something they don't easily accept. But it depends on the player/author.
There are cases going both ways in the high levels of chess. A game between Ljubojevic of Yugoslavia and Speelman of England was in a time scramble where Lljubojevic placed a piece between two squares (on the very edge) and Speelman adjusted (via adjoube) the piece the square Lljubojevic had not intended. They were playing a such a frantic pace at this moment that the players didn't notice the conflict until after a few moves when the time control was passed. Then Lljubojevic (in a now completely lost position) objected to the turn of events, the arbiter was called in and Speelman ruled in favor of Speelman. But Speelman realizing that he was going to win the game based on a misuderstanding immediately offered a draw which Ljubojevic accepted.
On the other hand Kasparov while playing against Judit Polgar (the female phenome in chess) actually *TOOK BACK A MOVE* while playing her. He had just reduced his professional sport to that of its most crybaby version. When Judit Polgar called the arbiter over in protest of what happened, though there were witnesses to the event in favor of Polgar's claims, the Arbiter actually ruled in favor of Kasparov! Rather than being a man and offering a draw or resigning immediately Kasparov went on to outplay her and win the game.
In this case I am sure that the author of the program which wanted to claim a draw just decided that Shredder had completely outplayed it and wanted to give it the honor of playing a complete game. I believe that the position was so lost for Shredder's opponent at this point that it could have resigned long time ago, however he was probably playing on as a matter of curiosity or fascination. Imagine if the author actually claimed a draw? I would have causes a minor uproar the other way -- why didn't he resign earlier? Why was he just playing to see if Shredder had a bug in it? Even if he *was* trying to test the opponents ability to drive the point home, he made his point without having to ruin the result of the game. I'm sure the author of Shredder is going to *FIX* the bug now.
Itanium is an excellent architecture. Its flaws come from politics:
1: Itanium requires good compilers. For now, that means compilers from Intel. GCC will be fine for running Mozilla on an Itanium, but technical apps simply won't perform anywhere near the performance of the machine when compied with GCC.
Compilers are not part of any politics. They are an integral part of the problem/solutions. Its not just that Itanium needs *good* compilers -- they need *UNGODLY AWESOME* compilers. The IA64 instructions do *NOT* naturally map to either Fortran or C primitives without a *LOT* of insightful transformations by the compiler. The only counter to this is that Intel themselves have in fact created quite excellent compilers. But the general excellence of Intel's compilers have only been verified on a wide array of applications on their *x86* platform. Whether or not Intel's amazing compiler feats which are seen on the x86 also translates to the vastly different instructions of IA64 on a *wide range* of software is an open question (and one that I highly suspect has a negative answer.)
2: Intel wants to market Itanium as a server chip. That means that they are putting 3MB or 6MB on the high end Itaniums. Soon they will have a 9MB cache version. Lots of cache means lots of transistors means lots of heat.
In general caches do not generate a lot of heat. The utility of a cache is measured roughly by the logarithm of their size, and both of the major x86 vendors now ship x86 CPUs with > 1MB on-chip L2 cache. The real problem with the big-cache Itanium solutions is that they use up so much god damned motherboard space, and draws just way too much power. All that for incremental performance advanges.
3: Intel is not fabbing Itanium with a state of the art process. Intel leads the world in process technology, yet their Itanium is still on a 130nm process. Before Madison (about a year ago), it was on a 180nm process.
No -- Intel leads in the narrow area of *x86-vendor* process technology. IBM still remains years ahead of anyone on generic process technology. The thing about Intel not using their own best process technology is indicative that the circuit designers are have a hard time translating the convoluted Itanium architecture to real world process technology.
1: Itanium is "inefficent". This couldn't be further from the truth. At 1.5Ghz, it whoops *anything* else in SPECfp (by a margin of 1.5x or more) and matches the 3.2Ghz P4 or 2.2Ghz Opteron in SPECint.
Itanium does well on Spec FP solely by virtue of its 6MB L3 cache configuration, however I would insist that you cite figures for your bogus SpecInt claim. A quick search on the www.spec.org shows this claim to be utterly false. Itanium2 is not even competitive. Also, the new Athlon FX and Pentium 4E CPUs kind of leave Itanium2 in the dust on Spec Int.
4: Itanium is expensive. This is true, but it has to do with politics rather than architecture. Itanium uses *fewer* transistors and does *more* instructions per clock than a RISC architecture.
This is Ari Fliescher level of deception. Itanium uses far more transisters (if you exclude on-chip caches) than any other CPU architecture. Its also makes no logical sense. General RISCs and the modern x86s use a single general idea of "Out of Order execution" which requires transisters to be spent on branch prediction, instruction buffers and rename registers. However, with Itanium matters are far worse. Instead of rename registsers they have register rotation scheme. They also have branch prediction but instead of instruction buffers, they have predication, fence posting, and instruction templates that's hardwired into their instruction set. Worse yet is that the whole Itanium1 versus Itanium2 sequence demonstrated that they require two full execution pipelines (which themselves i
It's the optimization step that causes issues: one of the main things the computer doesn't need which is stripped out is variable names, comments, etc. without them, there's no context. You can figure out the algorithm from the assembly, but you can't easily figure out what it's operating on....
All this is true, however, more programs tend to the use the standard language libraries, and/or STL. And if you have the right tools that can recognize usage of these, you can determine an aweful lot about what the source was trying to do in the first place.
Another thing to consider is that comments can often be misleading, and variable names might mean different things to different programmers.
Nosirree, no legitimate webmaster would ever use robots.txt to gently guide visiting bots to the appropriate parts of the site and to keep them from trying to do silly things.
So you're saying that the whitehouse.gov has limited their alternate color schemes and viewer editting capabilities to their Iraq (dis)information? It would explain a lot...
If I can prove to myself my vote was counted a certain way, so too can it be proved to others. And then votes get bought.
That's why the ballot (however the *F* it was created) has to be hand inspected by the voter in a reasonably private booth, then sealed in an uniform opaque envelope by the voter, then hand delivered to an open (and it probably should be transparent) ballot box.
This allows it to be proven to the voter herself, which is as well as can be done without allowing any external mapping from the voter to their vote.
No part of the election process should be hidden from the electorate
No *RELEVANT* part of the election process should be hidden. If you use some touch screen using some unknown proprietary software is irrelevant so long as it prints out a ballot which you put into a sealed envelop into a transparent box. The ballot can then be optically scanned (by a device which is also open to public view) to perform the operation of counting the votes.
Just listen. The executive summary: for some reason computer science people are the *ONLY* people who have the ability to understand how to run a fair election.
Ok you frothing Macaholics. *Someone* explain to me *how* such a largely clustered machine was put together with 80% efficiency *WITHOUT* ECC. This issue has been posted several times on this story, without any satisfactory answer.
If there are too many nodes the error rate goes up super-linearly (since interconnect errors have to be factored in.) There's no getting around this. If they are just running *without* ECC and hoping the results just come out correctly, then this is worthless -- its amounts to "fluke calculations".
You're willing to wait 7 years for the benchmark results to come out? They are benchmarks are of stable, well known, and pervasive applications. Not "seat of the pants, recompiled with some Beta compilers" toys that have some artificial reason for being 64bit. Laypeople like yourself are unaware of this, but I might as well tell you -- 64bit does not enhance performance. Even the Alpha engineers figured this out. The only thing it does is increase the addressable memory.
The POINT is that Apple never marketed the G5 as the fastest workstation. All Apple marketed the G5 as was the a) first 64-bit desktop and b) the fastest desktop around at the time.
AMD does not distinguish between desktop and workstation in their product lines, while Apple does. The reason is that one is a system vendor and the other is a CPU vendor. In order for Apple to be correct here, every system vendor in the world has to unilaterally declare that Athlon64s and Opertons can't be put into desktops. Given AMD's history in the CPU business so far, as much as Intel would hope for it, that seems highly unlikely.
I.e., the BOXX based opteron workstation that shipped in June of this year beats the pants off of Apple G5's shipping today, and is the first (serious) 64bit desktop to ship (workstations are desktops, BTW). So even AMD's own statements to the contrary (that Opterons were meant for servers) is irrelevant to the issue.
I.e., there has never ever been a point in time when the Apple G5 was shipping and ever has been the fastest desktop. The Opteron has been eclipsing it for its entire lifetime.
Furthermore, the Apple G5 was paper launched . It took them months to ship, unlike the Athlon 64s which shipped immediately upon launching (AMD's track record for doing this is remarkable -- they do this in order to underscore the fallacy of Intel's paper launches.) There may have been at most a two week window where G5's were shipping while AMD was not yet shipping Athlon 64s (but were shipping Opterons.)
And does anyone else see the possible conflict of interest with PC World running these benchmarks?
If you read the article you would see that they did it in cooperation with their sister publication MacWorld. There is also nothing in their disclosures that raises any eyebrows (unlike the ridiculous Veritest/Apple Spec CPU 2000 disclosures.)
The apple faithful modded my post as a troll of course.
Your question is a good one -- good enough, in fact, to seriously question the whole exercise. Automated hardware error detection and correction mechanism are a must because building them into software at a node-by-node level is at best application specific, and at worst reduces the cost benefit to 1 third.
The way you do this in software is to run *3* nodes doing the identical calculation. If all three agree there is no problem. If two agree then choose the agreeing results. If none agree reboot the machines and try again. Any detected failures are flagged and technicians may be automatically called to replace the failing units.
That's it. This Apple cluster is 3 times slower than advertised.
I thought this was already discussed -- this won't enter any list because the machine will not be able to stay up long enough to even run the benchmark correctly. The mean time before failure for such a highly parallel system that has no ECC memory mechanisms is just too high.
All of that said, if you want to buy the best x86 chip right now and money's no object -- buy Intel. Not because it's faster (it isn't), but because it's probably going to be more stable.
Remember that Athlon64 motherboard will be *MUCH SIMPLER* than previous generation 32-bit x86 motherboards since there is no seperate Northbridge that you need wired up. So there are fewer connections, and the mobo can be significantly smaller. Furthermore the power utilization of A64 has been much improved over the Athlon. I think that anything that AMD recommends or which is sold from the major vendors will be fine, and likely very comparable in stability versus anything from Intel.
Re:There's more to it than 64-bit instructions
on
Is Prescott 64-bit?
·
· Score: 1
To address those extra 4 bits you need to rearchitect the OS, the compiler, and your application (remember far pointers everyone?) All just to get a measely few more years of life out of 32-bit x86. Sorry, but that's a non-solution.
"You are stupid. Now you know you are stupid. We know you are stupid. Now you know that we know you are stupid. Remember that the next time you ask us a question."
Is it perhaps time for a code rewrite in Sendmail, or maybe a quiet, dignified retirement?
As with most legacy software, there is a large investment in the expertise people have built up in learning how to use/configure it. So retirement won't get rid of it. Rewriting it may just lead to creation of new security flaws (for example, openssh, is a far more modern code which is far more motivated to be secure from the get go, but as recent advisories/exploits have shown that doesn't make it magically bug-free) rather than moving towards the goal of eliminating them.
The right answer is to embark on a methodology for trying to root out the bugs, and/or use technologies that are intrinsically more resilient in the first place. While a rewrite in Java or Python are problematic ideas from the very get go (either requiring an installed and functional JVM, or being as slow as a post), one can at least address the ANSI C string library weakness (the obvious lowest hanging fruit) by using a substitute.
Look guys -- this is an opportunity. Microsoft thumbs their collective noses at Open Source people because they believe that they are more innovative. If the Linux community is able to put forth mechanisms, ideas, and possibly tools that truly address the "safe programming" issue, then this would be a quick slap in their face.
Steve Ballmer has started pounding his fist and making prognostications about how Microsoft is going to deal with security via their innovation. Of course its nonsense -- but people will only realize this *if* the Open Source community is able to step up to the plate and *demonstrate* their superior solution.
You'd think that it would be easy to fix this at the language level. It can't be that hard to create a string library that automatically ignores everything past the end of the string.
Seriously, its easy to learn, its very interoperable with char * buffers (and thus can be adopted incrementally without problems), its open source, and its safe by design. Oh yeah, its also a heck of a lot faster than the C library, and has a more functional API which leads to shorter and therefore more maintainable code.
Am I the only person who read the article?
on
Does C# Measure Up?
·
· Score: 3, Informative
First of all -- what's the deal with this whole "WARMUPS" thing? This is just the most explicit way possible of training the JIT mechanisms without measuring its overhead. That might be fine if you believe that the overhead asymptotically costs nothing, however, I don't know what evidence there is of this. The test should use other mechanisms other than this explicit mechanism to allow the language itself to demonstrate that the overhead is of low cost.
The way this test is set up, the JIT people could spend hours or days optimizing the code without it showing up in the tests. This is the wrong approach and will do nothing other than to encourage the JIT developers to cheat in a way such as this just to try to win these benchmarks.
Ok as to the specific tests:
1. FloatInteger conversion on x86 are notoriously slow and CPU micro-architecturally dependent. It also depends on your rounding standard -- the C standard dictates a rounding mode that forces the x86s into their slowest mode. However using the new "Prescott New Instructions", Intel has found a way around this issue that should eventually show up in the Intel C/C++ compiler.
This does not demonstrate anything about a language other than to ask the question of whether or not the overhead outside of the fi rises to the level of not overshadowing the slowness of the conversion itself.
(That said, obviously Intel's compiler knows something here that the other guys don't -- notice how it *RAPES* the competition.)
2. Integer to string conversion is just a question of the quality of the library implementation. A naive implement will just use divides in the inner loop, instead of one of the numerous "constant divide" tricks. Also, string to integer will use multiplies and still just be a limited to the quality of implementation as its most major factor determining performance.
3. The Pi calculation via iteration has two integer->floating point conversions and a divide in the inner loop. Again, this will make it limited to CPU speed, not language speed.
4. The Calculation of Pi via recursion is still dominated by the integer divide calculation. It will be CPU limited not language limited.
5. The Sieve of Erastothenes (sp?) is a fair test. However, if SLOTS is initialized to millions, and the comparable C implementation uses true bits, instead of integers, then I think the C implementation should beat the pants off of C#, Java, or anything else.
6. The string concatenation test, of course, is going to severely ding C for its pathetic string library implemenation (strcat, has an implicit strlen calculation in it, thus making it dramatically slower than it needs to be.) Using something like bstrlib would negate the advantage of C#, Java, or any other language.
7. The string comparison with switch is a fair test, and gives each language the opportunity to use whatever high level "insight" that the compiler is capable of delivering on. It should be noted that a sufficiently powerful C compiler should be capable of killing its competition on this test, however, I don't believe any C compiler currently in existence is capable of demonstrating this for this case. I.e., this *could* be a legitimate case to demonstrate that C# or Java's high level abstractions give it an advantage over where the state of the art is in C compilers today.
8. Of course the tokenization is another serious ding on the rather pathetic implementation of the C library. None of strtok, strspn, etc are up to the task of doing serious high performance string tokenization. If you use an alternative library (such as bstrlib or even just PCRE) you would find that C would be impossible to beat.
-----
Ok, while the results here are interesting, I don't think there were enough tests here to truly test the language, especially in more real world (and less laboratory-like) conditions. Please refer to The Great Win32 Computer Language Shootout for a more serious set of tests.
No string implementation for C/C++ can be perfect, as I'm sure you well realize, having written one yourself.
Well, it would be a stretch for me to call bstrlib perfect, however it does significantly raise the bar in terms of safety, speed and usefulness. It solves all the major problems of string manipulations in the C library without introducing any new ones. I would argue that SafeStr does not accomplish this same thing.
If you're holding references to an object (whether it's a SafeStr string or something else entirely), do not modify the object.
Why not? You see, you are making the same mistake that the designers of the original C library are making. You are creating a sematic restriction that is not reflected as a syntactical restriction. This is exactly what buffer overflows are all about -- careless programmers write code that is syntactically ok, and works according to some mediocre testing and some defective model they have in their head about how their program is supposed to behave. Programmers will always make this mistake. The job of someone who is trying to make a "safe" library is to reduce or eliminate the amount of damage that can happen as a result of incorrect programming by reducing or eliminating the number of ways that the programmer can go wrong. Your implicit restriction here, which can only be supported by diligent programming and reading the manual, is precisely where the problem is.
You are correct in saying that any string that is modified with references may cause the other references to be left in an undefined state. Unfortunately, this is a problem with any sort of reference counting in C unless you abstract away the pointer and replace it with a handle (a la Win32) or something similar.
Right... so why didn't you abstract away the pointer with a handle like everyone else does? The justification you give in your documentation kind of rings hollow if you compare it to the way bstrlib does it. Interoperability with char * buffer libraries is important (and well supported with bstrlib semantics) but enforcing that your base type actually be essentially a char * is not a necessary consequence.
You are also correct with your second point; however, this is a limitation that is clearly documented.
Well... all of the C libraries weakness are also well documented. That doesn't seem to prevent programmers from ignoring the documentation and doing the wrong thing anyway.
Both of these problems are minor, obvious issues that aren't a big deal in practice.
Sorry, but I'm going to have to highly disagree here. In *PRACTICE* I like using the "const" decorator on function parameters -- something you can't effectively do with SafeStr. The idea of obtaining a reference to something asynchronously with it contents is also a useful programming concept that's been with us for decades.
SafeStr is *a* solution, but it is not intended to be *the* solution. Its trade-offs may not be acceptable to everyone, whereas those offered by bstring or other string implementations may be instead.
If there are "trade-offs" in bstrlib, I am unaware of them.
Slashdot Mirror
Factoring composite is probably somewhat easier in the sense that it doesn't require more hardware/brute force computational power, however, its probably harder in the sense that you need to be very famillar with the very latest in factoring algorithms and essentially be skilled and willing enough to implement the very leading edge known algorithms.
In other words, factoring RC5-72 requires Moore's law, plus a massively growing audience of people willing to participate. But even with the most optimistic projections, RC5-72 will not fall for decades. Factoring something like RSA-574 requires that you be up on the latest in computational mathematics as it relates to number theory. If you think you can bone up on the latest in factoring techniques in less than 10 years, then you probably have a better shot at the RSA prizes.
Lecture on "Trusted Computing"
There are cases going both ways in the high levels of chess. A game between Ljubojevic of Yugoslavia and Speelman of England was in a time scramble where Lljubojevic placed a piece between two squares (on the very edge) and Speelman adjusted (via adjoube) the piece the square Lljubojevic had not intended. They were playing a such a frantic pace at this moment that the players didn't notice the conflict until after a few moves when the time control was passed. Then Lljubojevic (in a now completely lost position) objected to the turn of events, the arbiter was called in and Speelman ruled in favor of Speelman. But Speelman realizing that he was going to win the game based on a misuderstanding immediately offered a draw which Ljubojevic accepted.
On the other hand Kasparov while playing against Judit Polgar (the female phenome in chess) actually *TOOK BACK A MOVE* while playing her. He had just reduced his professional sport to that of its most crybaby version. When Judit Polgar called the arbiter over in protest of what happened, though there were witnesses to the event in favor of Polgar's claims, the Arbiter actually ruled in favor of Kasparov! Rather than being a man and offering a draw or resigning immediately Kasparov went on to outplay her and win the game.
In this case I am sure that the author of the program which wanted to claim a draw just decided that Shredder had completely outplayed it and wanted to give it the honor of playing a complete game. I believe that the position was so lost for Shredder's opponent at this point that it could have resigned long time ago, however he was probably playing on as a matter of curiosity or fascination. Imagine if the author actually claimed a draw? I would have causes a minor uproar the other way -- why didn't he resign earlier? Why was he just playing to see if Shredder had a bug in it? Even if he *was* trying to test the opponents ability to drive the point home, he made his point without having to ruin the result of the game. I'm sure the author of Shredder is going to *FIX* the bug now.
Compilers are not part of any politics. They are an integral part of the problem/solutions. Its not just that Itanium needs *good* compilers -- they need *UNGODLY AWESOME* compilers. The IA64 instructions do *NOT* naturally map to either Fortran or C primitives without a *LOT* of insightful transformations by the compiler. The only counter to this is that Intel themselves have in fact created quite excellent compilers. But the general excellence of Intel's compilers have only been verified on a wide array of applications on their *x86* platform. Whether or not Intel's amazing compiler feats which are seen on the x86 also translates to the vastly different instructions of IA64 on a *wide range* of software is an open question (and one that I highly suspect has a negative answer.)
In general caches do not generate a lot of heat. The utility of a cache is measured roughly by the logarithm of their size, and both of the major x86 vendors now ship x86 CPUs with > 1MB on-chip L2 cache. The real problem with the big-cache Itanium solutions is that they use up so much god damned motherboard space, and draws just way too much power. All that for incremental performance advanges.
No -- Intel leads in the narrow area of *x86-vendor* process technology. IBM still remains years ahead of anyone on generic process technology. The thing about Intel not using their own best process technology is indicative that the circuit designers are have a hard time translating the convoluted Itanium architecture to real world process technology.
Itanium does well on Spec FP solely by virtue of its 6MB L3 cache configuration, however I would insist that you cite figures for your bogus SpecInt claim. A quick search on the www.spec.org shows this claim to be utterly false. Itanium2 is not even competitive. Also, the new Athlon FX and Pentium 4E CPUs kind of leave Itanium2 in the dust on Spec Int.
This is Ari Fliescher level of deception. Itanium uses far more transisters (if you exclude on-chip caches) than any other CPU architecture. Its also makes no logical sense. General RISCs and the modern x86s use a single general idea of "Out of Order execution" which requires transisters to be spent on branch prediction, instruction buffers and rename registers. However, with Itanium matters are far worse. Instead of rename registsers they have register rotation scheme. They also have branch prediction but instead of instruction buffers, they have predication, fence posting, and instruction templates that's hardwired into their instruction set. Worse yet is that the whole Itanium1 versus Itanium2 sequence demonstrated that they require two full execution pipelines (which themselves i
Another thing to consider is that comments can often be misleading, and variable names might mean different things to different programmers.
AltiVec cannot be used in the Linpack test. Linpack required 64 bit floating point which is not supported with AltiVec (it is in SSE-2, though.)
This allows it to be proven to the voter herself, which is as well as can be done without allowing any external mapping from the voter to their vote.
No *RELEVANT* part of the election process should be hidden. If you use some touch screen using some unknown proprietary software is irrelevant so long as it prints out a ballot which you put into a sealed envelop into a transparent box. The ballot can then be optically scanned (by a device which is also open to public view) to perform the operation of counting the votes.
Indeed. In fact being open source has nothing to do with it. See:
/ 031008-ee380-100.asx
http://www.acm.org/classics/sep95/
then see:
http://stanford-online.stanford.edu/courses/ee380
I was under the impression that they already had webspace outside of the US:
http://www.indymedia.ca/
http://www.indymedia.ch/
http://indymedia.org.uk/
http://www.indymedia.org.nz/
http://www.indymedia.nl/
http://bulgaria.indymedia.it/
or do these all map map to some server in San Francisco?
http://stanford-online.stanford.edu/courses/ee380/ 031008-ee380-100.asx
Just listen. The executive summary: for some reason computer science people are the *ONLY* people who have the ability to understand how to run a fair election.
Ok you frothing Macaholics. *Someone* explain to me *how* such a largely clustered machine was put together with 80% efficiency *WITHOUT* ECC. This issue has been posted several times on this story, without any satisfactory answer.
If there are too many nodes the error rate goes up super-linearly (since interconnect errors have to be factored in.) There's no getting around this. If they are just running *without* ECC and hoping the results just come out correctly, then this is worthless -- its amounts to "fluke calculations".
You're willing to wait 7 years for the benchmark results to come out? They are benchmarks are of stable, well known, and pervasive applications. Not "seat of the pants, recompiled with some Beta compilers" toys that have some artificial reason for being 64bit. Laypeople like yourself are unaware of this, but I might as well tell you -- 64bit does not enhance performance. Even the Alpha engineers figured this out. The only thing it does is increase the addressable memory.
I.e., the BOXX based opteron workstation that shipped in June of this year beats the pants off of Apple G5's shipping today, and is the first (serious) 64bit desktop to ship (workstations are desktops, BTW). So even AMD's own statements to the contrary (that Opterons were meant for servers) is irrelevant to the issue.
I.e., there has never ever been a point in time when the Apple G5 was shipping and ever has been the fastest desktop. The Opteron has been eclipsing it for its entire lifetime.
Furthermore, the Apple G5 was paper launched . It took them months to ship, unlike the Athlon 64s which shipped immediately upon launching (AMD's track record for doing this is remarkable -- they do this in order to underscore the fallacy of Intel's paper launches.) There may have been at most a two week window where G5's were shipping while AMD was not yet shipping Athlon 64s (but were shipping Opterons.)
If you read the article you would see that they did it in cooperation with their sister publication MacWorld. There is also nothing in their disclosures that raises any eyebrows (unlike the ridiculous Veritest/Apple Spec CPU 2000 disclosures.)
The apple faithful modded my post as a troll of course.
Your question is a good one -- good enough, in fact, to seriously question the whole exercise. Automated hardware error detection and correction mechanism are a must because building them into software at a node-by-node level is at best application specific, and at worst reduces the cost benefit to 1 third.
The way you do this in software is to run *3* nodes doing the identical calculation. If all three agree there is no problem. If two agree then choose the agreeing results. If none agree reboot the machines and try again. Any detected failures are flagged and technicians may be automatically called to replace the failing units.
That's it. This Apple cluster is 3 times slower than advertised.
I thought this was already discussed -- this won't enter any list because the machine will not be able to stay up long enough to even run the benchmark correctly. The mean time before failure for such a highly parallel system that has no ECC memory mechanisms is just too high.
To address those extra 4 bits you need to rearchitect the OS, the compiler, and your application (remember far pointers everyone?) All just to get a measely few more years of life out of 32-bit x86. Sorry, but that's a non-solution.
I kind of read that whole "Any Key" this as:
"You are stupid. Now you know you are stupid. We know you are stupid. Now you know that we know you are stupid. Remember that the next time you ask us a question."
The right answer is to embark on a methodology for trying to root out the bugs, and/or use technologies that are intrinsically more resilient in the first place. While a rewrite in Java or Python are problematic ideas from the very get go (either requiring an installed and functional JVM, or being as slow as a post), one can at least address the ANSI C string library weakness (the obvious lowest hanging fruit) by using a substitute.
Look guys -- this is an opportunity. Microsoft thumbs their collective noses at Open Source people because they believe that they are more innovative. If the Linux community is able to put forth mechanisms, ideas, and possibly tools that truly address the "safe programming" issue, then this would be a quick slap in their face.
Steve Ballmer has started pounding his fist and making prognostications about how Microsoft is going to deal with security via their innovation. Of course its nonsense -- but people will only realize this *if* the Open Source community is able to step up to the plate and *demonstrate* their superior solution.
Seriously, its easy to learn, its very interoperable with char * buffers (and thus can be adopted incrementally without problems), its open source, and its safe by design. Oh yeah, its also a heck of a lot faster than the C library, and has a more functional API which leads to shorter and therefore more maintainable code.
First of all -- what's the deal with this whole "WARMUPS" thing? This is just the most explicit way possible of training the JIT mechanisms without measuring its overhead. That might be fine if you believe that the overhead asymptotically costs nothing, however, I don't know what evidence there is of this. The test should use other mechanisms other than this explicit mechanism to allow the language itself to demonstrate that the overhead is of low cost.
The way this test is set up, the JIT people could spend hours or days optimizing the code without it showing up in the tests. This is the wrong approach and will do nothing other than to encourage the JIT developers to cheat in a way such as this just to try to win these benchmarks.
Ok as to the specific tests:
1. FloatInteger conversion on x86 are notoriously slow and CPU micro-architecturally dependent. It also depends on your rounding standard -- the C standard dictates a rounding mode that forces the x86s into their slowest mode. However using the new "Prescott New Instructions", Intel has found a way around this issue that should eventually show up in the Intel C/C++ compiler.
This does not demonstrate anything about a language other than to ask the question of whether or not the overhead outside of the fi rises to the level of not overshadowing the slowness of the conversion itself.
(That said, obviously Intel's compiler knows something here that the other guys don't -- notice how it *RAPES* the competition.)
2. Integer to string conversion is just a question of the quality of the library implementation. A naive implement will just use divides in the inner loop, instead of one of the numerous "constant divide" tricks. Also, string to integer will use multiplies and still just be a limited to the quality of implementation as its most major factor determining performance.
3. The Pi calculation via iteration has two integer->floating point conversions and a divide in the inner loop. Again, this will make it limited to CPU speed, not language speed.
4. The Calculation of Pi via recursion is still dominated by the integer divide calculation. It will be CPU limited not language limited.
5. The Sieve of Erastothenes (sp?) is a fair test. However, if SLOTS is initialized to millions, and the comparable C implementation uses true bits, instead of integers, then I think the C implementation should beat the pants off of C#, Java, or anything else.
6. The string concatenation test, of course, is going to severely ding C for its pathetic string library implemenation (strcat, has an implicit strlen calculation in it, thus making it dramatically slower than it needs to be.) Using something like bstrlib would negate the advantage of C#, Java, or any other language.
7. The string comparison with switch is a fair test, and gives each language the opportunity to use whatever high level "insight" that the compiler is capable of delivering on. It should be noted that a sufficiently powerful C compiler should be capable of killing its competition on this test, however, I don't believe any C compiler currently in existence is capable of demonstrating this for this case. I.e., this *could* be a legitimate case to demonstrate that C# or Java's high level abstractions give it an advantage over where the state of the art is in C compilers today.
8. Of course the tokenization is another serious ding on the rather pathetic implementation of the C library. None of strtok, strspn, etc are up to the task of doing serious high performance string tokenization. If you use an alternative library (such as bstrlib or even just PCRE) you would find that C would be impossible to beat.
-----
Ok, while the results here are interesting, I don't think there were enough tests here to truly test the language, especially in more real world (and less laboratory-like) conditions. Please refer to The Great Win32 Computer Language Shootout for a more serious set of tests.
Why not? You see, you are making the same mistake that the designers of the original C library are making. You are creating a sematic restriction that is not reflected as a syntactical restriction. This is exactly what buffer overflows are all about -- careless programmers write code that is syntactically ok, and works according to some mediocre testing and some defective model they have in their head about how their program is supposed to behave. Programmers will always make this mistake. The job of someone who is trying to make a "safe" library is to reduce or eliminate the amount of damage that can happen as a result of incorrect programming by reducing or eliminating the number of ways that the programmer can go wrong. Your implicit restriction here, which can only be supported by diligent programming and reading the manual, is precisely where the problem is.
Right
Well
Sorry, but I'm going to have to highly disagree here. In *PRACTICE* I like using the "const" decorator on function parameters -- something you can't effectively do with SafeStr. The idea of obtaining a reference to something asynchronously with it contents is also a useful programming concept that's been with us for decades.
If there are "trade-offs" in bstrlib, I am unaware of them.