The general idea is that it will take a relatively small yet significant time to compute. So for example (also random) 30 seconds. Joe Sixpack will not notice 30 second delay on his computer for one email.
Yes he will. Because that 30 seconds of 100% CPU utilization. To make sure its not annoying to mail senders, its got to be something really short like 3 seconds or something (that would be my personal threshold). But then there's the question of whether or not its enough of a burden on spammers.
Ah, was waiting for this one: (*) Mailing lists and other legitimate email uses would be affected One word, one hyphen: white-listing.
That doesn't change the fact that people have to successfully mail you for the first time. The reason people don't use whitelists today is because it affects normal email flow.
(*) Users of email will not put up with it Why? It's not costing them anything
You are not measuring people's time, effort, and annoyance factor in dealing with a change in technology.
(*) Ideas similar to yours are easy to come up with, yet none have ever been shown practical None have ever been tried.
There's a reason "sender pays" is a well known catch-phrase in Spam circles -- its been kicking around for a *LONG* time.
Your better string library only deals with strings, but buffer overflows occur in many different data types. And C/C++ make it easy to make a large number of other mistakes that lead to safety and/or security problems.
Two points: 1) The Better String Library expands the definition of strings to include any continguous binary sequence (including embedded '\0's). It uses this fact to implement a more powerful and abstract file stream as well, for example (it works with binary files, and has an infinite "ungetc()"). 2) Research by David Wagner (a well known cryptographer) and others have determined that string buffer overflows are the vast majority of all buffer overflow related problems -- in fact the functions in the bsafe module in the Better String Library correspond exactly to the functions most likely to be involved in a buffer overflow problem.
And even within your better string library, you still require programmers to be rather careful.
Uhh... well in C/C++ you always have be somewhat careful because of silly things like dereferencing a pointer before its initialized. But other than that using the Better String Library takes care of so much of the details automatically. The programmer's carefulness can be redirected to higher level concerns, and more typical concerns of the core C/C++ programming language. Let me be clear -- the Better String Library takes the pressure OFF the programmer with regards to string manipulation. So while I would never recommend that a programmer decrease their vigilance, the Better String Library can only increase their safety.
Your better string library doesn't even get close to what is possible with careful, high-quality coding in C/C++.
Excuse me? can you cite something specific? I am not aware of any string library that is safer than the Better String Library.
If it were that simple, than there should be no buffer overflows in modern C/C++ programs. But it apparently isn't that simple, for several reasons. Using container libraries costs extra time and effort, and it is less efficient than error checking that is built into the compiler, for example. Also, using container libraries is not something that the C/C++ compilers help enforce; that is, if some module doesn't use it, nobody ever gets warned about it.
False on ALL counts! Allow me to introduce you to the Better String Library for C and C++. This library handles strings and growable block buffers in general.
Because of its superior API (closer to higher level languages, and a superset of what C/C++ has to offer) it is Easier to use than the C/C++ alternatives. (The functions do more and do things that other languages have done with strings for a long time.)
Because of its superior architecture (length delimited) and implementation (uses the fastest corners of the state of the art in C/C++ compiler technology) it is Faster than the C/C++ alternatives. (I've got the benchmark numbers to prove it)
It comes with the optional bsafe module that creates link overrides to the standard C library functions where buffer overflows occurr most often and which are redundant to functionality in the Better String Library. I.e., deprecation of bad C library routines can be Enforced.
And, of course, the API is completely buffer overflow safe.
This library has been thoroughly tested, its portable, its open source, and is currently used in projects such as Myriad and the Small Language. I assert that moving away from C/C++ in an attempt to escape buffer overflows is not only misguided, but unnecessary if you use the the Better String Library. The whole "using C/C++ inevitably leads to buffer overflows" idea gets thrown out the window if you are using it. I would encourage any C/C++ programmer to try it out before concluding that you need to move away from C/C++.
Are you sure that if MSIE, Mozilla and Opera all screw up on your table that the table isn't messed up?
Yes I am sure. Smaller versions of the same table work, and it passes the w3c verfier's scrutiny. There is nothing wrong with the HTML, its really a problem that *all* browsers seem to have.
Though, I've just rechecked, and I'm sure you've be surprised to hear -- FireFox seems to be the first browser I've encountered to correctly render it.
No, there is no mistake, and my website is not particularly aimed at Open Source or Linux advocates (though it is somewhat technical). There was a sharp rise in non-IE browsers a year ago, and its been like this for some time now.
Although MyIE2 and Netcaptor are really just plugins to IE, they advertise themselves as being a distinct product from IE. So I am counting them seperately.
The "Other" category is actually populated by a lot of new robots that my tools haven't previously recognized, strange things like bookmark checkers, spidering tools, proxies, or other things whose User Agent string makes no sense at all (like: "Your Bunny Wrote (Windows)" -- what the hell is that?)
So even taking into account the weird propensity of non-IE users to visit my site, you cannot deny that there has been an increase in total Firefox use and that IE use has declined in hits to my site.
The big rise in Robots is due solely to msnbot/0.3. (Though this has not lead to a rise in hits coming from msn searches.)
About my site: http://www.azillionmonkeys.com/ its a technical programmer site with a lot of outgoing links and a google rank of 5 out of 10. It is also completely compatible with the top 3 major browsers (except that all of them screw up on the massively sized table shown here: http://www.azillionmonkeys.com/qed/amultl2.html).
Is Quartz some unoptimized piece of garbage? All graphics rendering (either 2D or 3D) is done by accelerated graphics cards these days. Are you saying that Quartz is more computationally intensive than video games like Unreal Tournament which are very responsive?
... Microsoft developers are the lamest programmers in the world. Some choice quotes:
Run this macro for a while, and you get a "Disk is full" error on one of the saves, at which point you can no longer save your document.... the basic theme of the problem is to hit an open file limit...
Excuse me, but first of all, an "open file limit" and a "Disk is full" error are two slightly different things. The first thing that is wrong is that the wrong error message is being displayed. 10 years of debugging could have been cut short by actually reporting the correct error message.
Because this problem wouldn't reproduce under the debugger, the developer had no way of knowing exactly where the failure was occurring.
So the only bugs Microsoft developers can solve in a reasonable amount of time are those that conveniently show up in their debuggers (otherwise it will take them 10 years)? Debugging without a debugger is one of the first skills that, what I would call, an "advanced coder" learns.
here's a tip you can use until we release an SR of Word X (or earlier) with this fix. If you have a document that has headers and footers with page fields in them, do your editing in Normal view, and you'll likely never hit the "Disk is full" save error.
And if I understood the rest of the article correctly -- the fix is not a systemic deterministic fix. Its just a method for mitigating the problem in the scenario in the one way in which they have been able to observe it.
This is the unravelling of a convoluted web which they are tring to piece together with scotch tape, bandaids and spit. Its pathetic. Their problem is an "running out of file handles" issue. They need to solve the problem definitively -- if they cannot rewrite the architecture of the code, then they need to write a virtual file layer that can have an unlimited number of file handles. Or something comparable.
These pathetic one-off patches that seem to be just barely mated to the specific problem manifestation just increase the complexity of the code.
I am roughly as strong as GNU/Chess. I suck. All the top programs (that does not include GNU Chess or Crafty) play at strong to super grandmaster strength (Crafty plays at IM or weak grandmaster strength), and the top 4 or 5 programs (which includes Shredder) all play at around World Champion strength.
Re:Your information is incorrect
on
Hydra vs. Shredder
·
· Score: 2, Informative
There was no specific action taken to specifically tune DB to Kasparov. Its tuning was primarily in the hands of feedback from a number of the top US players (probably none of which had ever played Kasparov) and the ingenuity of Feng Hsu, it primary designer.
Kasparov doesn't have a style of play that you can just put your finger on and say "oh, I know how to counter that!". The closest anyone has come to doing that is when Vladimir Kramnik beat him in a World Championship match in 2000. And Kramnik did it in a style that no computer could ever hope to emulate.
Deep Blue's primary "tuning" was directed at just making sure it played chess really really well. The VLSI doesn't have any specific "anti-Kasparov logic" in it at all. They used a combination of brute force and state of the art in heuristic evaluation of chess positions. Feng Hsu also revolutionized game tree search technology with a method he created called "singular extension", which I believe most chess programs now use in one form or another.
They also let Kasparov psyche himself out and play in an extremely unusual style that he is not really known for. Commenting on the games from the audience Viswanathan Anand (currently second in the world) said basically he couldn't believe or understand the way Kasparov was playing.
As to the whole dismantling thing, IBM actually had smaller versions of DB playing exhibition games against all comers for a little while after the match before shutting down the whole thing. An earlier version of DB called Deep Thought II, also entered the World Computer Chess Championships soon after, and lost the championship and its individual game to Fritz running on a single CPU PC.
You can make MD5 (actually SHA-1 would be preferrable) arbitrarily slow by appending an arbitrarily long fixed (per passwd file) suffix at the end of the input password, so that brute force becomes far less effective.
This suffix could even be public, and need not be totally random -- a determiniscally generated pseudo random number sequence based on about 32 bits of entropy (so that 4 billtion times the dictionary is required to perform a pure dictionary attack.) Then just generate a length for this suffix to blow out the L2 cache of all reasonable CPUs -- say 16MBs. On my system it takes less than a second to perform this calculation, so it doesn't make the login process much worse, but this will clearly make the computation of any reasonably sized dictionary infeasible.
Dictionary attacks are only good for people who have passwords that come from the dictionary. The password program itself can sniff such simple passwords out and reject them at the time the password is picked.
However, having gone to the trouble to shoot and edit the movie with high enough quality for movie projection, I'd want the highest possible quality to be downloadable.
Clearly you have not seen Moore's documentaries before. He's got maybe 35mm or worse yet maybe camcorder quality in many sections. Going for top image quality has never been Moore's foremost considerations in making his films.
So unless the back of people's heads, or audience reaction noise (which I assume is going to be fairly disruptive for most cam corder jobs) is what you want to get rid of, I'd say you needn't bother about the image quality.
Its a motion sensor. (The idea is even if you are "standing still" you move very subtly, and the radar can pick it up.) It aint going to help you find studs.
It was actually the G4 because it was the first processor that could pull a gigaflop.
Just Apple's reality distorion field.
1. Clinton lifted the 1 Gigaflop restriction (or at the very least substantially increased it) because the Alpha processor was already in violation far before the AltiVec enabled G3 ever shipped. (Apple then started running those commercials claiming it was a super computer, but there was never any export issue with them.)
2. The AMD *K6* processor (with 3DNow!) actually was the first commodity processor that exceeded 1 GigaFlop (once it reached 350Mhz). It shipped prior the ban lifting, and nobody realized that there was a problem until *after* the ban was lifted. (Trust me, I have inside knowledge on this.)
His point is that: why doesn't the compiler/linker/environment help find the errors that programmers make?
He questions why gcc only issues warnings in cases where the generated code can't possibly be right. He goes a little too far by suggesting that we should just plug a GC wrapper into malloc/free (this changes the memory footprint of the program) but his ideas are sound.
Very few programmers have been railing about the inherent danger of the programming environment, and the total lack of help from the compiler. Of course *I* was one of them:
Maybe bab 5 had the whole 5 year story arc, but the acting was TERRIBLE! worse than star trek and that's saying something!
Ignoring the fact that I disagree with you, there are other things in Bab 5 that make it a superior show:
1) Innovative Sci Fi ideas (alien in an encounter suit, doing 2 pairs of correctly coherent connected time travel episodes seperated by 3 several years.) 2) Digital Special Effects -- for a weekly television show, I think they still stand at the very top (Dune is better here, but that was a movie). 3) Costume Special Effects -- G'Kar is easily the best makeup for a regular TV alien. 4) Music by Christopher Frankie, from Tangerine Dream. 5) No truly stupid plot devices or super abuse of physics (like replicators, or holodecks (they never *once* went back in time to 1995 era earth, in any way shape or form)). 6) Incredible attention to plausible believability. In particular watch the episode where they present forensic evidence to indict the Centauri for attacks on shipping lines.
But going back to the acting, I've got to say that I've hardly ever seen any actors better than Peter Jurasik, Andreas Katsulas, Stephen Furst or Walter Koenig. I think Mira Furla was an unfortunate choice, especially given the importance of her character, but other than that I cannot think of anyone who acted really badly in the show.
These are the top 500 that we know about. What do you bet the NSA (and whatever the Chinese and possibly the Russian equivalents are) has at least 1 that is faster than all of these?
Unlikely. There's a reason Earth Simulator has been #1 for like 3 years now. You can't just throw more hardware at the problem. You have to throw money, and design into it. Even secretive organizations like the NSA have their technical and even monetary limits.
These secretive organizations used to probably have the fastest machines, but we're talking about an era that preceeds off the shelf supercomputers and intense competition on this list. I'm willing to believe that the top 10 or 20 or so, are the true top computers.
Personally, I think JMS should take that Trek idea and run with it in a new Universe, the way they did with Babylon 5. Bab-5 is by far one of the best Sci-Fi series ever produced, and it came from a rejected Star Trek idea pitch.
Yes, and Babylon 5 stands as the best Sci Fi TV show ever created. But its ratings at its peak never reached even the lowest ratings of the worst of the Star Trek series.
The *name* Star Trek has a built-in automatic audience that will be recognized by the networks. Star Trek's biggest weakness since TNG has been the poor writing. The natural solution is to use the ST name, and JMS' superior writing to try to fix the show. JMS has figured it out, now its just a question of whether or not Braga and Perlman can figure it out.
Gcc is designed for compatibility with a wide range of architectures, and is not optimized for a single one. He also (apparantly) used stock glibc from Red Hat. And only one "test", the method call test, showed java to be a real winner. And even then, it's server-side Java, which is meaning less when you talk about it as a day-to-day dev language (ie; creating standalone client-side apps).
Intel's (heavily optimized) C++ compiler should be a damn sight faster, and so should VC++.
This is a slight misrepresentation. gcc actually does quite respectably on x86 platforms -- its easily as good as MSVC++, and its clear that the gcc people have put a lot of work into this compiler. Of course, the Intel C++ compiler is truly awesome and leaves pretty much every other x86 compiler in the dust, but this is really a case of Intel just putting a truly amazing effort into their compiler rather than anyone else comming up short.
The real issue with these tests is that pretty much none of them have real computational inner loops. They all measure unlikely program overhead that could easily be removed with any reasonable rerendering of the code.
Re:you have no idea what you're talking about
on
Java Faster Than C++?
·
· Score: 1, Informative
Are you trolling or what?
I am a professional programmer with plenty of math background. Besides running a porno-site, who are you?
This is known as the "halting problem"....
No it's not. In fact, it's not even close to the definition of the "halting problem". The Halting Problem is "Given input X, and program Y, will Y ever finish it's calculation, and halt on when given X as an input". It's a 'problem' for which no computer program can be written to solve.
I didn't say its the definition of the problem. But you clearly don't understand how this definition applies to the real world. For any algorithm to determine whether or not a recursion has a simple degeneration to an iterative formula requires solving arbitrarily complex math problems.
Solving or knowing if these math problems can be solved is equivalent to the halting problem.
The point is that the best compilers can do here is pattern matching which isn't going to be worth it for the relative infrequency of any given special cases.
erm... I only checked the fibonacci routine, but it's actually quite funny - he's branching recursive calls, a clear case when a smart-enough runtime optimization would work better. I mean, any reasonably smart optimizer would eventually figure out that there are too many calls to the same function with the same argument to just stand by and watch. I'd say that given this difference c++ did quite alright in that one.
This is known as the "halting problem". No, the compiler cannot guarantee the ability to transform a recursive solution to a non-recursive one. The case of the fibonacci algorithm is a particularly difficult one to transform properly if the compiler hasn't special cased it.
That said -- Ack and Fib are call overhead limited. They examples of poor quality code whose performance is not inner loop based.
Hash will be C-string (specifically strcmp and sprintf) limited in performance. The performance is therefore very data dependent (since Java uses length delimited strings.) Using a fast string class such as "The Better String Library" (http://bstring.sf.net) would have yielded C++ far better performance. A similar comment applies to the strcat test.
The Heapsort is a particularly bad implementation. In good implementations, the Intel compiler really takes gcc to town. See: http://www.azillionmonkeys.com/qed/sort.html
Integer Matrix multiplying is an extremely rare application. So I wouldn't put too much stock in the results here -- though, I would be surprised if there was much differentiation between either Java of C++ on this test.
The method calling, I think, will be very much limited by the compiler's ability to inline past method calls. I think Intel C/C++ differentiates itself on such things.
The Nestedloop and random tests are interesting -- I don't see how Java is supposed to beat C++ on it, but its possible to be equal.
I don't know enough about the Java object system and barely enough about C++ object system to comment on sieve or objinst.
It seems to me that sumcol and wc are going to be IO limited.
I don't think this test is exactly fair, as the code is not representative for tasks where performance really matters.
Slashdot Mirror
- The general idea is that it will take a relatively small yet significant time to compute. So for example (also random) 30 seconds. Joe Sixpack will not notice 30 second delay on his computer for one email.
Yes he will. Because that 30 seconds of 100% CPU utilization. To make sure its not annoying to mail senders, its got to be something really short like 3 seconds or something (that would be my personal threshold). But then there's the question of whether or not its enough of a burden on spammers.- Ah, was waiting for this one:
That doesn't change the fact that people have to successfully mail you for the first time. The reason people don't use whitelists today is because it affects normal email flow.(*) Mailing lists and other legitimate email uses would be affected
One word, one hyphen: white-listing.
- (*) Users of email will not put up with it
You are not measuring people's time, effort, and annoyance factor in dealing with a change in technology.Why? It's not costing them anything
- (*) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
There's a reason "sender pays" is a well known catch-phrase in Spam circles -- its been kicking around for a *LONG* time.None have ever been tried.
- Your better string library only deals with strings, but buffer overflows occur in many different data types. And C/C++ make it easy to make a large number of other mistakes that lead to safety and/or security problems.
Two points: 1) The Better String Library expands the definition of strings to include any continguous binary sequence (including embedded '\0's). It uses this fact to implement a more powerful and abstract file stream as well, for example (it works with binary files, and has an infinite "ungetc()"). 2) Research by David Wagner (a well known cryptographer) and others have determined that string buffer overflows are the vast majority of all buffer overflow related problems -- in fact the functions in the bsafe module in the Better String Library correspond exactly to the functions most likely to be involved in a buffer overflow problem.- And even within your better string library, you still require programmers to be rather careful.
Uhh- Your better string library doesn't even get close to what is possible with careful, high-quality coding in C/C++.
Excuse me? can you cite something specific? I am not aware of any string library that is safer than the Better String Library.- If it were that simple, than there should be no buffer overflows in modern C/C++ programs. But it apparently isn't that simple, for several reasons. Using container libraries costs extra time and effort, and it is less efficient than error checking that is built into the compiler, for example. Also, using container libraries is not something that the C/C++ compilers help enforce; that is, if some module doesn't use it, nobody ever gets warned about it.
False on ALL counts! Allow me to introduce you to the Better String Library for C and C++. This library handles strings and growable block buffers in general.- Because of its superior API (closer to higher level languages, and a superset of what C/C++ has to offer) it is Easier to use than the C/C++ alternatives. (The functions do more and do things that other languages have done with strings for a long time.)
- Because of its superior architecture (length delimited) and implementation (uses the fastest corners of the state of the art in C/C++ compiler technology) it is Faster than the C/C++ alternatives. (I've got the benchmark numbers to prove it)
- It comes with the optional bsafe module that creates link overrides to the standard C library functions where buffer overflows occurr most often and which are redundant to functionality in the Better String Library. I.e., deprecation of bad C library routines can be Enforced.
- And, of course, the API is completely buffer overflow safe.
This library has been thoroughly tested, its portable, its open source , and is currently used in projects such as Myriad and the Small Language. I assert that moving away from C/C++ in an attempt to escape buffer overflows is not only misguided, but unnecessary if you use the the Better String Library. The whole "using C/C++ inevitably leads to buffer overflows" idea gets thrown out the window if you are using it. I would encourage any C/C++ programmer to try it out before concluding that you need to move away from C/C++.- GCC is no slouch though [...]
Yes it is- [...] and obviously Intel is performing some tricks that could also be implemented by GCC.
Its not like the Intel compiler group is resting on its laurels. GCC has been getting its ass kicked by Intel's compiler for about 5 years now.Though, I've just rechecked, and I'm sure you've be surprised to hear -- FireFox seems to be the first browser I've encountered to correctly render it.
These are the stats on my site (by percent):
MSIE: 60.30%
FireFox: 12.03%
Robot: 10.21%
Mozilla: 5.26%
Other: 3.66%
Opera: 3.26%
Netscape: 1.63%
Safari: 1.30%
MyIE2: 0.87%
Konqueror: 0.59%
Wget: 0.36%
StumbleUpon: 0.19%
Galeon: 0.12%
NetCaptor: 0.09%
Avant: 0.05%
Camino: 0.03%
Links: 0.03%
Lynx: 0.01%
Dillo: 0.01%
No, there is no mistake, and my website is not particularly aimed at Open Source or Linux advocates (though it is somewhat technical). There was a sharp rise in non-IE browsers a year ago, and its been like this for some time now.
Although MyIE2 and Netcaptor are really just plugins to IE, they advertise themselves as being a distinct product from IE. So I am counting them seperately.
The "Other" category is actually populated by a lot of new robots that my tools haven't previously recognized, strange things like bookmark checkers, spidering tools, proxies, or other things whose User Agent string makes no sense at all (like: "Your Bunny Wrote (Windows)" -- what the hell is that?)
Top stats from a year ago:
MSIE: 72.30%
Mozilla: 8.91%
Robot: 5.45%
Other: 4.20%
Opera: 3.24%
Netscape: 1.70%
FireFox: 1.03%
So even taking into account the weird propensity of non-IE users to visit my site, you cannot deny that there has been an increase in total Firefox use and that IE use has declined in hits to my site.
The big rise in Robots is due solely to msnbot/0.3. (Though this has not lead to a rise in hits coming from msn searches.)
About my site: http://www.azillionmonkeys.com/ its a technical programmer site with a lot of outgoing links and a google rank of 5 out of 10. It is also completely compatible with the top 3 major browsers (except that all of them screw up on the massively sized table shown here: http://www.azillionmonkeys.com/qed/amultl2.html).
... Because if it is, can we vote timothy off the island?
Is Quartz some unoptimized piece of garbage? All graphics rendering (either 2D or 3D) is done by accelerated graphics cards these days. Are you saying that Quartz is more computationally intensive than video games like Unreal Tournament which are very responsive?
Excuse me, but first of all, an "open file limit" and a "Disk is full" error are two slightly different things. The first thing that is wrong is that the wrong error message is being displayed. 10 years of debugging could have been cut short by actually reporting the correct error message.
So the only bugs Microsoft developers can solve in a reasonable amount of time are those that conveniently show up in their debuggers (otherwise it will take them 10 years)? Debugging without a debugger is one of the first skills that, what I would call, an "advanced coder" learns.
And if I understood the rest of the article correctly -- the fix is not a systemic deterministic fix. Its just a method for mitigating the problem in the scenario in the one way in which they have been able to observe it.
This is the unravelling of a convoluted web which they are tring to piece together with scotch tape, bandaids and spit. Its pathetic. Their problem is an "running out of file handles" issue. They need to solve the problem definitively -- if they cannot rewrite the architecture of the code, then they need to write a virtual file layer that can have an unlimited number of file handles. Or something comparable.
These pathetic one-off patches that seem to be just barely mated to the specific problem manifestation just increase the complexity of the code.
I am roughly as strong as GNU/Chess. I suck. All the top programs (that does not include GNU Chess or Crafty) play at strong to super grandmaster strength (Crafty plays at IM or weak grandmaster strength), and the top 4 or 5 programs (which includes Shredder) all play at around World Champion strength.
There was no specific action taken to specifically tune DB to Kasparov. Its tuning was primarily in the hands of feedback from a number of the top US players (probably none of which had ever played Kasparov) and the ingenuity of Feng Hsu, it primary designer.
Kasparov doesn't have a style of play that you can just put your finger on and say "oh, I know how to counter that!". The closest anyone has come to doing that is when Vladimir Kramnik beat him in a World Championship match in 2000. And Kramnik did it in a style that no computer could ever hope to emulate.
Deep Blue's primary "tuning" was directed at just making sure it played chess really really well. The VLSI doesn't have any specific "anti-Kasparov logic" in it at all. They used a combination of brute force and state of the art in heuristic evaluation of chess positions. Feng Hsu also revolutionized game tree search technology with a method he created called "singular extension", which I believe most chess programs now use in one form or another.
They also let Kasparov psyche himself out and play in an extremely unusual style that he is not really known for. Commenting on the games from the audience Viswanathan Anand (currently second in the world) said basically he couldn't believe or understand the way Kasparov was playing.
As to the whole dismantling thing, IBM actually had smaller versions of DB playing exhibition games against all comers for a little while after the match before shutting down the whole thing. An earlier version of DB called Deep Thought II, also entered the World Computer Chess Championships soon after, and lost the championship and its individual game to Fritz running on a single CPU PC.
You can make MD5 (actually SHA-1 would be preferrable) arbitrarily slow by appending an arbitrarily long fixed (per passwd file) suffix at the end of the input password, so that brute force becomes far less effective.
This suffix could even be public, and need not be totally random -- a determiniscally generated pseudo random number sequence based on about 32 bits of entropy (so that 4 billtion times the dictionary is required to perform a pure dictionary attack.) Then just generate a length for this suffix to blow out the L2 cache of all reasonable CPUs -- say 16MBs. On my system it takes less than a second to perform this calculation, so it doesn't make the login process much worse, but this will clearly make the computation of any reasonably sized dictionary infeasible.
Dictionary attacks are only good for people who have passwords that come from the dictionary. The password program itself can sniff such simple passwords out and reject them at the time the password is picked.
In the scholars mate demo they have 2. ... Kc6 which is a little bit illegal
However, having gone to the trouble to shoot and edit the movie with high enough quality for movie projection, I'd want the highest possible quality to be downloadable.
Clearly you have not seen Moore's documentaries before. He's got maybe 35mm or worse yet maybe camcorder quality in many sections. Going for top image quality has never been Moore's foremost considerations in making his films.
So unless the back of people's heads, or audience reaction noise (which I assume is going to be fairly disruptive for most cam corder jobs) is what you want to get rid of, I'd say you needn't bother about the image quality.
Its a motion sensor. (The idea is even if you are "standing still" you move very subtly, and the radar can pick it up.) It aint going to help you find studs.
It was actually the G4 because it was the first processor that could pull a gigaflop.
Just Apple's reality distorion field.
1. Clinton lifted the 1 Gigaflop restriction (or at the very least substantially increased it) because the Alpha processor was already in violation far before the AltiVec enabled G3 ever shipped. (Apple then started running those commercials claiming it was a super computer, but there was never any export issue with them.)
2. The AMD *K6* processor (with 3DNow!) actually was the first commodity processor that exceeded 1 GigaFlop (once it reached 350Mhz). It shipped prior the ban lifting, and nobody realized that there was a problem until *after* the ban was lifted. (Trust me, I have inside knowledge on this.)
His point is that: why doesn't the compiler/linker/environment help find the errors that programmers make?
He questions why gcc only issues warnings in cases where the generated code can't possibly be right. He goes a little too far by suggesting that we should just plug a GC wrapper into malloc/free (this changes the memory footprint of the program) but his ideas are sound.
Very few programmers have been railing about the inherent danger of the programming environment, and the total lack of help from the compiler. Of course *I* was one of them:
http://bstring.sf.net/
(The bsafe module overrides the most unsafe string function calls, thus forcing the developer to use the safe alternatives.)
http://www.pobox.com/~qed/userInput.html
(A way of using strong typing as a mechanism for duplicating the functionality of "tainting".)
Maybe bab 5 had the whole 5 year story arc, but the acting was TERRIBLE! worse than star trek and that's saying something!
Ignoring the fact that I disagree with you, there are other things in Bab 5 that make it a superior show:
1) Innovative Sci Fi ideas (alien in an encounter suit, doing 2 pairs of correctly coherent connected time travel episodes seperated by 3 several years.)
2) Digital Special Effects -- for a weekly television show, I think they still stand at the very top (Dune is better here, but that was a movie).
3) Costume Special Effects -- G'Kar is easily the best makeup for a regular TV alien.
4) Music by Christopher Frankie, from Tangerine Dream.
5) No truly stupid plot devices or super abuse of physics (like replicators, or holodecks (they never *once* went back in time to 1995 era earth, in any way shape or form)).
6) Incredible attention to plausible believability. In particular watch the episode where they present forensic evidence to indict the Centauri for attacks on shipping lines.
But going back to the acting, I've got to say that I've hardly ever seen any actors better than Peter Jurasik, Andreas Katsulas, Stephen Furst or Walter Koenig. I think Mira Furla was an unfortunate choice, especially given the importance of her character, but other than that I cannot think of anyone who acted really badly in the show.
These are the top 500 that we know about. What do you bet the NSA (and whatever the Chinese and possibly the Russian equivalents are) has at least 1 that is faster than all of these?
Unlikely. There's a reason Earth Simulator has been #1 for like 3 years now. You can't just throw more hardware at the problem. You have to throw money, and design into it. Even secretive organizations like the NSA have their technical and even monetary limits.
These secretive organizations used to probably have the fastest machines, but we're talking about an era that preceeds off the shelf supercomputers and intense competition on this list. I'm willing to believe that the top 10 or 20 or so, are the true top computers.
Personally, I think JMS should take that Trek idea and run with it in a new Universe, the way they did with Babylon 5. Bab-5 is by far one of the best Sci-Fi series ever produced, and it came from a rejected Star Trek idea pitch.
Yes, and Babylon 5 stands as the best Sci Fi TV show ever created. But its ratings at its peak never reached even the lowest ratings of the worst of the Star Trek series.
The *name* Star Trek has a built-in automatic audience that will be recognized by the networks. Star Trek's biggest weakness since TNG has been the poor writing. The natural solution is to use the ST name, and JMS' superior writing to try to fix the show. JMS has figured it out, now its just a question of whether or not Braga and Perlman can figure it out.
Gcc is designed for compatibility with a wide range of architectures, and is not optimized for a single one. He also (apparantly) used stock glibc from Red Hat. And only one "test", the method call test, showed java to be a real winner. And even then, it's server-side Java, which is meaning less when you talk about it as a day-to-day dev language (ie; creating standalone client-side apps).
Intel's (heavily optimized) C++ compiler should be a damn sight faster, and so should VC++.
This is a slight misrepresentation. gcc actually does quite respectably on x86 platforms -- its easily as good as MSVC++, and its clear that the gcc people have put a lot of work into this compiler. Of course, the Intel C++ compiler is truly awesome and leaves pretty much every other x86 compiler in the dust, but this is really a case of Intel just putting a truly amazing effort into their compiler rather than anyone else comming up short.
The real issue with these tests is that pretty much none of them have real computational inner loops. They all measure unlikely program overhead that could easily be removed with any reasonable rerendering of the code.
Are you trolling or what?
...
I am a professional programmer with plenty of math background. Besides running a porno-site, who are you?
This is known as the "halting problem".
No it's not. In fact, it's not even close to the definition of the "halting problem". The Halting Problem is "Given input X, and program Y, will Y ever finish it's calculation, and halt on when given X as an input". It's a 'problem' for which no computer program can be written to solve.
I didn't say its the definition of the problem. But you clearly don't understand how this definition applies to the real world. For any algorithm to determine whether or not a recursion has a simple degeneration to an iterative formula requires solving arbitrarily complex math problems.
Solving or knowing if these math problems can be solved is equivalent to the halting problem.
The point is that the best compilers can do here is pattern matching which isn't going to be worth it for the relative infrequency of any given special cases.
erm ... I only checked the fibonacci routine, but it's actually quite funny - he's branching recursive calls, a clear case when a smart-enough runtime optimization would work better. I mean, any reasonably smart optimizer would eventually figure out that there are too many calls to the same function with the same argument to just stand by and watch. I'd say that given this difference c++ did quite alright in that one.
This is known as the "halting problem". No, the compiler cannot guarantee the ability to transform a recursive solution to a non-recursive one. The case of the fibonacci algorithm is a particularly difficult one to transform properly if the compiler hasn't special cased it.
That said -- Ack and Fib are call overhead limited. They examples of poor quality code whose performance is not inner loop based.
Hash will be C-string (specifically strcmp and sprintf) limited in performance. The performance is therefore very data dependent (since Java uses length delimited strings.) Using a fast string class such as "The Better String Library" (http://bstring.sf.net) would have yielded C++ far better performance. A similar comment applies to the strcat test.
The Heapsort is a particularly bad implementation. In good implementations, the Intel compiler really takes gcc to town. See: http://www.azillionmonkeys.com/qed/sort.html
Integer Matrix multiplying is an extremely rare application. So I wouldn't put too much stock in the results here -- though, I would be surprised if there was much differentiation between either Java of C++ on this test.
The method calling, I think, will be very much limited by the compiler's ability to inline past method calls. I think Intel C/C++ differentiates itself on such things.
The Nestedloop and random tests are interesting -- I don't see how Java is supposed to beat C++ on it, but its possible to be equal.
I don't know enough about the Java object system and barely enough about C++ object system to comment on sieve or objinst.
It seems to me that sumcol and wc are going to be IO limited.
I don't think this test is exactly fair, as the code is not representative for tasks where performance really matters.