Caught up to what? SSE-1 + SSE-2, which are the comparable techonologies to Altivec, both shipped *BEFORE* Altivec. Furthermore, anyone who has watched the x86 world to any degree has seen Intel and AMD actually *SLOWING DOWN* lately. They pushed a little too hard on Moore's law during 2001 - 2003, and are having a hard time just keeping up with their own pace. If anything, they are joining the x86 arena during a period of relative lull.
... While bugs in hardware is nothing new (the P4 has 64 known issues, at this time Intel does not plan to fix a single one) this marks one of the first times that Intel released a processor with known bugs,...
Huh? That's clearly wrong. When Intel had its famous FDIV bug, they shipped it knowing that the problem was there (the chips were already manufactured before they noticed it in their internal design validation.) In fact I would highly doubt that any Intel chip (or AMD chip) has shipped without some known bugs in them.
Its just a question of severity. Most of these bugs tend to be highly marginal in a "real software doesn't push that hard on the CPU" sense.
Well that's about the only good thing in this list.
* They want us to hack a Diebold optical scan version 1.96.6 system which has never been used or certified in California and has probably been modified *after* the Hursti report was released.
What's the point in auditing something that has never been used, and for which there is not proof that it will ever be used, or that it won't be "upgraded" in the future?
* The test conditions were to be very limited and with a time limit (which they haven't decided on yet).
This is meaningless. The time-limit should be "as long as it takes". (A few days would probably be sufficient.)
* The test machines would be supplied by Diebold.
Who actually owns or posessed the machines used? Are they leased or something? Obviously you want to audit a machine that's actually been used, or which is supposed to be used in the actual election.
This is like a magician telling you to pick a card from the top of a deck that he prepared and didn't shuffle.
* We would not be allowed to do any hacking we don't tell them about ahead of time - in other words, no "tire kicking".
So Diebold gets to rig up a special machine to defeat a few very narrowly described hacks that you have fully described up front? I don't call this an audit.
* They get to videotape everything, we are banned from bringing cameras.
Ridiculous! An audit without a report to all parties concerned is not an audit at all.
* The public isn't invited.
That just sounds punitive and just additional restrictions to let Diebold control everything about the situation.
* Diebold has had five months to prep for this thing, we get less than two weeks.
Prep time should not be relevant. Just bring the real machine in, give experts on both sides time to examine things until the thing can be considered auditted.
Most of these restrictions are ridiculous, superfluous and clearly designed to give Diebold the ability to completely control and direct this "audit". Their purpose is obvious; they want to put out the press release: "We invited the most antagonistic elements to audit our system and they were not able to find any flaw in the system" after convincing you to take part in this charade where obviously you will not find what you are looking for.
I don't know what the right response is for you people, but clearly the state officials are being "handled" by Diebold here. You have to find some way expose or work against or break this down.
English speakers read left-to-right, and the subject nearly always precedes the object in a sentence. "if (5 == x)" may keep you from doing accidental assignments, but it also reads the same way "red is my car" would.
If you have an intuitive problem with the way that reads, its not the problem with the code, its a problem with your intuition. The test of "My car is red" translates to if (car.color == red) which is the same as if (red == car.color) or "the color of my car is red" or "red is the color of my car". Its the same -- your perception of a difference is in of itself a likely source of bugs.
The idea of putting constants on the left side (and using const as a parameter or value attribute whenever possible) is a technique that only has upside (ignoring programmers with "intuition failures").
[...] but most programs haven't even got the ability to hyperthread, so do we really need the extra cores?
Writing code for hyperthreading is not easier than writing code for multi-code/SMP. Both are just writing code targetted for SMP. NUMA-like concerns, for systems with multiple chips make more of a difference. If anything, hyperthreading is harder to optimize for, since you have to figure out when to issue PAUSE instructions.
I seriously don't understand anyone's statistics. I have a website that is not particularly aligned with FOSS and I have never seen MS IE above 75%. You can see longer term statistics here:
Of course I am counting robots (they are essentially my control group, to make sure my stats are consistent) by that's never more than 12.5%. Ok, in any event, the other thing I am seeing is that Firefox started by gaining marketshare at an enormous rate. Like others have stated, the fact that the "second derivative" has been forced to negative is just a side effect of the insane initial growth.
This month so far looks like IE @ 54% and FF @ 20% BTW. So yes, its unlikely that FF will gain the insane 6% or 8% -- its more like 2.5%. Oh yeah, at a lot of FF's market share has come at the expense of Mozilla, of course, and it looks like Opera is slowly starting to give up some of its share to FF as well. But the balance, of course, is coming from IE.
Yes: but they are all Intel compatible... what about some interesting comparisons like: IBM's power PC, Sun's SPARC, IBM mainframe,...
Because those processors will score 0 on 3DMark, SiSoft Sandra, and just about any other video games used in the comparison. Any more stupid questions?
Its not exactly the C library per se, but instead a complete substitute for one part of the C library that is the source for a lot of headaches and security issues; namely strings.
In short, its slow, it doesn't have bounds protection, has slow interopability with char * strings, has mediocre functionality (no insert, no overwrite, no find-replace, no split/join, no useful line-input). Various implementations have thread safety problems, and I don't know if it is aliasing safe.
Of course it is possible to implement safe and powerful string handling in C++ (http://bstring.sf.net/) but std::string is not a solution that is comparable to the abilities other languages.
Let me preface this by saying I was recently on a 3-week vacation in Costa Rica where I got to see a lot of the country.
Most Costa Ricans have cellphones, and DSL internet access either at home, a library, or in the neighborhood internet cafe.
You are smoking crack. I saw very few cellphones in this country -- even in San Jose (the most metropolitain city I visited). Internet in the home is way over the pay scale of most Costa Ricans. In San Jose, broadband does exist, but you pay for it. In most other cities, its basically at dial-up speeds, and internet cafes are the only way anyone could afford to access the internet at all.
The economy is very efficient, and it runs an American-style government on only a 13% tax base. What this means for the individuals who live there is that instead of two people in a family working 50+ hours a week to make a living, one person in a Costa Rican can make a living.
I didn't get a real sense for the domestic working schedules of people in Costa Rica, but in San Jose, we were renting a room from a cottage run exclusively by women. The economy in Costa Rica is majorly subsidized by Intel which has a very large plant down there, and the whole "Eco-tourism" craze. Us stupid foreigners pay $2000 a pop to go watch common every day animals climb up what to us look like exotic palm trees and what they consider house plants. Other than that, Del Monte and Dole have basically split the country into halves and are selling fruits from the plentiful fertile soil that Costa Rica has. Oh yeah, and they sell some coffee there too.
Most Costa Ricans make about $12 per day.
Uhh... this varies quite a *lot*. There's no way in hell people in San Jose only make $12 a day. Its less than americans, but it aint no $12. Cab/Bus rides, food, trinkets, hotels, etc -- in San Jose, they are probably at about 50% of american salaries.
In other inland cities like MonteVerde, of course, things are very different and you very well might be correct. We were in a really nice hotel that cost us like $15 per person.
But the Costal cities which are so heavily subsidized by tourism, these guys are not living on the cheap; that's for sure (these are $100 rooms, $20 meals, etc).
Doesn't sound like a lot, but since the public transportation is well designed, no one needs cars.
This is nonsense. In San Jose, people had cars just as much as americans do -- and the jaywalking ettiquette is quite different.:) In other cities this varied, but the only real limiting factor in car ownership, that I noticed, was whether or not the city had paved roads.
a vacation to the USA,
Perhaps for the more well to do Costa Ricans, but I don't see what possible motivation any Costa Rican would have for visiting the US. We've got crappy food, useless beaches, the most horrendously egotistical tourist attractions, and we wouldn't even *try* to speak spanish to give them directions.
Americans go to Costa Rica mostly for prostitution, so the people they encounter like to encourage their notions so that it makes the Americans feel superior, and looser with their money.
Uhh... not *THIS* american! Costa Rica is a major tourist country even without the "eco-tourism". They've got beaches on BOTH oceans. Some are very suitable great surfing. The number of tours you can go to are practically uncountable -- the amount of wildlife, both plant and animals I saw in such a short amount of time was probably more than I've ever seen in my life. In an open air restaurant, we saw a sloth climbing up a tree that wasn't even part of any tour!
There was a warning at the airport about child prostitution, but that's all I noticed. There certainly didn't seem to be a lot of open rampant prostitution, but maybe we just didn't go to the right places.
Dude, I think your view of Costa Rica is extremely skewed. This is obvious from the fact that you don't even recognize just how varied the country is.
Unfortunately, I've posted -- otherwise I would used my mod points to indicate this as a troll or overrated or something.
The two expressions are semantically identical. There is no difference between the two. So "any programmer" who sees a distinction between the two, is just a defective programmer. Just use the one that follows your "coding conventions" if you've got them, or just use the one you are used to.
This level of inane minutia is not what I would call "real programming", any more than typing skills are.
Saravana Kannan asks: "I have been coding in C for a while (10 yrs or so) and tend to use short code snippets. As a simple example, take 'if (!ptr)' instead of 'if (ptr==NULL)'. The reason someone might use the former code snippet is because they believe it would result in smaller machine code if the compiler does not do optimizations or is not smart enough to optimize the particular code snippet. IMHO the latter code snippet is clearer than the former, and I would use it in my code if I know for sure that the compiler will optimize it and produce machine code equivalent to the former code snippet. The previous example was easy. What about code that is more complex? Now that compilers have matured over years and have had many improvements, I ask the Slashdot crowd, what they believe the compiler can be trusted to optimize and what must be hand optimized?"
Most compilers come with something called a disassembler. Or better yet, you can trace the code with an assembly level debugger. If you want to know whether or not your compiler produces good code, why don't you just look at your code and find out? I'll bet dollars to donuts that you have one of these tools sitting on your hard drive that will tell you what your compiler did. Seriously, if you don't know how to get the answer to the question for yourself, then you don't deserve to know the answer.
Most compilers today will get all the simple stuff like if (!ptr) vs if (NULL == ptr) optimization. Its the more complex things that the compiler cannot "prove" where it has trouble. For example:
void h(int x, int y) {
for (i=0; i < N; i++) {
if (0 != (x & (1 << y))) {
f(i);
} else {
g(i);
}
} }
Very few compilers will dare simplify this to:
void h(int x, int y) {
if (0 != (x & (1 << y))) {
for (i=0; i < N; i++) f(i);
} else {
for (i=0; i < N; i++) g(i);
} }
Because the compilers have a hard time realizing that the conditional is constant and should be hoisted to the outside of the for loop. The compiler has the opportunity to perform loop unrolling in the second form that its may not try in the first instance.
You can learn these things from experience, or you can simply figure it out for yourself with the afore mentioned decompilation tools.
Oh for crying out loud, can we please stop posting this "X-files" nonsense as if its for real? As if we don't have enough propaganda and lies being blasted our way in our media.
Look, we're talking about ESP. If you can't get James Randi to believe it, please don't bother us about it.
Re:Info on what exactly SHA-1 is ...
on
SHA-1 Broken
·
· Score: 5, Interesting
DES had a weakness nobody but the NSA knew about, so they recommended changes to it without saying the reasons for them. years later an attack was found against DES, but the NSA changes prevented it from being useful. Why would they change their tune to SHA-1?
You know, of course, that the NSA did the same thing with SHA right? The original algorithm submitted was SHA-0, then the NSA recommended an unexplained minor change.
Last August SHA-0 was broken, so their tweak appears to have added about 6 months of extra life for SHA-1.
You simply have to model the the essential game state variables, then create a method for "serializing" them into something that can be thrown out to disk. There is no need at all for these variables to be global, just make sure you pass a "game context" down the call stack to any function which can modify the game state.
The reason why its important to have this abstraction, is that its required in order to make in-game demos, and to have any hope of writing a networked version of your game. It can also let you do strange things like split screen the game and let two people play independent games if you like (a speed contest, for example.)
Well completely automating it is probable not the right answer. Often people will submit a link to a.HTML page, which itself links to the larger file (like a movie) that causes their server to run out of bandwidth.
The Coral cache will only cache the top-most link -- and its actually left to the HTML author to coral cache the final contents. An example is a page I wrote here:
The root html file is not cached at all, but its fairly small, so I'm not worried about it. All those pictures though? There ain't no way I would post such a link in slashdot if I had to pay for the bandwidth to serve up those pictures myself!
So this is really a message to HTML authors and slashdot story submitters.
... This set again needs more mirrors (I still can't download the torrent files)....
What the hell are you talking about? How can people be so damn slow as to not realize how the Coral cache works?
Just create a raw typical URL for the thing, then write some HTML with the suffix: ".nyud.net:8090" on the end, and like magic you get free, virtually unlimited, and extremely reliable of bandwidth.
First, I will agree with the general premise that performance of systems has not corresponded to the promise of Moore's law or other advertisements. However, I have many disagreements with what has been written here.
- The corrollary of "component size" halving every 18 months (its actually
more like 20-24 months) is that the switching time is also correspondingly
reduced. This is what allows clock rates to increase in rough proportion to
Moore's law. So *YES* you should expect clock rates to improve as process
technology improves. Also, as component size decreases, the numer of
transistors that can be put into a given fixed size for a chip increases.
This gives designers more ability to create more sophisticated logic, or
simply increase cache sizes. So, besides expecting clock rate increases,
Moore's law suggests micro-architectural performance should also improve
over time.
- In the Windows world, anti-aliased fonts have been around since the mid to
late 90s and they have 0 impact on real performance. There is an ever so
slight complexity overhead in describing how the anti-aliasing occurrs, but
otherwise the operations are handled by the graphics driver and graphics
card. And in the Windows world, this and any other graphics operations
have been thoroughly scrutinized over the years by the massive amounts and
availability of graphics benchmarks. There is no monitor in existence that
can keep up with the raw pixel output performance of any graphics card
rendering any realistic amount of anti-aliased text -- i.e., there is no
way a human being could actually *see* the performance difference between
anti-aliased text or any other form of rendered text on a modern machine.
- As to the word processor -- most people turn off the paper clip and other
do-dads. And those who don't very rarely complain about the performance of
their machine. In the Windows world, on-the-fly WYSIWYG rendering has been
at realtime speeds since the early to mid 90s, which puts their
corresponding CPU clock rates at roughly the 50-100 Mhz range. Once again,
the vast availability of performance benchmarks has been a driving factor
in this. Automatic grammar and spell checkers run in the background --
i.e., they only use processor cycles that are not committed to more
important user feedback.
- Security of general software is about how well they have been designed and
how rigorously they have been tested. The comment about virus scanning
software is correct, however, many people do not *use* virus scanning
software (as is evidenced by the continued problem.) So this does not
explain the real performance issues.
- Program complexity is indeed at the heart of most of the problem, but you
have not clearly explained why. Most of these applications are written in
the C++ language. C++ is both a blessing and a curse, because it allows
developers to write far more sophisticated software (than in C) but unless
the developer is careful the penalty comes in performance. But the thing
about C++ is that its is almost always possible to recover all the
performance, if only enough examination and design of the critical paths is
done during development. In otherwords, in theory, there should be no
performance penalty for this more sophisticated software, but for some
reason there is.
My claim is the primary reason for this is the relative dearth of system
performance benchmarks. The only thing that motivates developers to improve
performance is if their customers complain -- that is, customers armed with
real numbers to back them up.
Since Ziff-Davis has pretty much gotten out of serious benchmarking in their main magazine publications (except for video games) system/software
I'd hope not because for most problems efficient *algorithms* are more important than efficient implementation.
Yes, but often implementing efficient algorithms comes down to reading a text book you might happen to have handy -- which then means implementation *does* become the most important (remaining) factor. That's why people still think about quicksort, even though heapsort is already theoretically at least its equal.
STREAM is not a real world app. Its just a massively parallel vector copy/sum/dot-product. Every SMP kernel in the world (even the older Linuxes) should be able to scale STREAM perfectly well.
The HPL results are more impressive, but keep in mind that linear equation solving code has advanced quite considerably (i.e., it tends to behave a lot like STREAM) to the point that its not very limited by kernel behavior.
No, he's referring to ALL video card vendors. I have worked for 2 different such companies, and I did this to drivers to make sure they passed WHQL, or tricked a benchmark or whatever.
The tone of the article almost has an edge of "I can't believe we do this in our industry I feel so dirty!" to it. The poster of the story is obviously some kind of new college hire or hasn't been in the industry for very long or something. All vendors do this, all the time. Its just the way it is.
Ok, so now you apply the Wang et al. mechanism to start filling the md5_collision_play_area with stuff to find a collision pair. Then you have a 50% chance of finding a pair such that one version of the application runs the goodApplication() while the other runs Virus(). This means that on average, you have to run the collision construction mechanism twice before you get a pair that execute that condition with opposite results.
So then you publicize the file which runs the goodApplication() and publish the MD5 and advertise its functionality as the goodApplication() (which maybe you stole from somewhere.) Then one day you just switch it for its doppleganger (with the same MD5) which runs the virus version.
Is this not a way to exploit the MD5 weakness *today*?
I have to second that. My feeling on it is when they had a meeting with a blank piece of paper to design this chip they only invited hardware people. All the tough stuff has been moved into software.
Slashdot Mirror
Caught up to what? SSE-1 + SSE-2, which are the comparable techonologies to Altivec, both shipped *BEFORE* Altivec. Furthermore, anyone who has watched the x86 world to any degree has seen Intel and AMD actually *SLOWING DOWN* lately. They pushed a little too hard on Moore's law during 2001 - 2003, and are having a hard time just keeping up with their own pace. If anything, they are joining the x86 arena during a period of relative lull.
Huh? That's clearly wrong. When Intel had its famous FDIV bug, they shipped it knowing that the problem was there (the chips were already manufactured before they noticed it in their internal design validation.) In fact I would highly doubt that any Intel chip (or AMD chip) has shipped without some known bugs in them.
Its just a question of severity. Most of these bugs tend to be highly marginal in a "real software doesn't push that hard on the CPU" sense.
You guys *REALLY* want to see the Commodore 64 come back? Take a look at Here, and here.
What's the point in auditing something that has never been used, and for which there is not proof that it will ever be used, or that it won't be "upgraded" in the future?
This is meaningless. The time-limit should be "as long as it takes". (A few days would probably be sufficient.)
Who actually owns or posessed the machines used? Are they leased or something? Obviously you want to audit a machine that's actually been used, or which is supposed to be used in the actual election.
This is like a magician telling you to pick a card from the top of a deck that he prepared and didn't shuffle.
So Diebold gets to rig up a special machine to defeat a few very narrowly described hacks that you have fully described up front? I don't call this an audit.
Ridiculous! An audit without a report to all parties concerned is not an audit at all.
That just sounds punitive and just additional restrictions to let Diebold control everything about the situation.
Prep time should not be relevant. Just bring the real machine in, give experts on both sides time to examine things until the thing can be considered auditted.
Most of these restrictions are ridiculous, superfluous and clearly designed to give Diebold the ability to completely control and direct this "audit". Their purpose is obvious; they want to put out the press release: "We invited the most antagonistic elements to audit our system and they were not able to find any flaw in the system" after convincing you to take part in this charade where obviously you will not find what you are looking for.
I don't know what the right response is for you people, but clearly the state officials are being "handled" by Diebold here. You have to find some way expose or work against or break this down.
The idea of putting constants on the left side (and using const as a parameter or value attribute whenever possible) is a technique that only has upside (ignoring programmers with "intuition failures").
I seriously don't understand anyone's statistics. I have a website that is not particularly aligned with FOSS and I have never seen MS IE above 75%. You can see longer term statistics here:
http://www.pobox.com/~qed/sitestats.html
Of course I am counting robots (they are essentially my control group, to make sure my stats are consistent) by that's never more than 12.5%. Ok, in any event, the other thing I am seeing is that Firefox started by gaining marketshare at an enormous rate. Like others have stated, the fact that the "second derivative" has been forced to negative is just a side effect of the insane initial growth.
This month so far looks like IE @ 54% and FF @ 20% BTW. So yes, its unlikely that FF will gain the insane 6% or 8% -- its more like 2.5%. Oh yeah, at a lot of FF's market share has come at the expense of Mozilla, of course, and it looks like Opera is slowly starting to give up some of its share to FF as well. But the balance, of course, is coming from IE.
Well I've done part of one:
http://bstring.sf.net/
Its not exactly the C library per se, but instead a complete substitute for one part of the C library that is the source for a lot of headaches and security issues; namely strings.
In short, its slow, it doesn't have bounds protection, has slow interopability with char * strings, has mediocre functionality (no insert, no overwrite, no find-replace, no split/join, no useful line-input). Various implementations have thread safety problems, and I don't know if it is aliasing safe.
Of course it is possible to implement safe and powerful string handling in C++ (http://bstring.sf.net/) but std::string is not a solution that is comparable to the abilities other languages.
You are smoking crack. I saw very few cellphones in this country -- even in San Jose (the most metropolitain city I visited). Internet in the home is way over the pay scale of most Costa Ricans. In San Jose, broadband does exist, but you pay for it. In most other cities, its basically at dial-up speeds, and internet cafes are the only way anyone could afford to access the internet at all.
I didn't get a real sense for the domestic working schedules of people in Costa Rica, but in San Jose, we were renting a room from a cottage run exclusively by women. The economy in Costa Rica is majorly subsidized by Intel which has a very large plant down there, and the whole "Eco-tourism" craze. Us stupid foreigners pay $2000 a pop to go watch common every day animals climb up what to us look like exotic palm trees and what they consider house plants. Other than that, Del Monte and Dole have basically split the country into halves and are selling fruits from the plentiful fertile soil that Costa Rica has. Oh yeah, and they sell some coffee there too.
Uhh
In other inland cities like MonteVerde, of course, things are very different and you very well might be correct. We were in a really nice hotel that cost us like $15 per person.
But the Costal cities which are so heavily subsidized by tourism, these guys are not living on the cheap; that's for sure (these are $100 rooms, $20 meals, etc).
This is nonsense. In San Jose, people had cars just as much as americans do -- and the jaywalking ettiquette is quite different.
Perhaps for the more well to do Costa Ricans, but I don't see what possible motivation any Costa Rican would have for visiting the US. We've got crappy food, useless beaches, the most horrendously egotistical tourist attractions, and we wouldn't even *try* to speak spanish to give them directions.
Uhh
There was a warning at the airport about child prostitution, but that's all I noticed. There certainly didn't seem to be a lot of open rampant prostitution, but maybe we just didn't go to the right places.
Dude, I think your view of Costa Rica is extremely skewed. This is obvious from the fact that you don't even recognize just how varied the country is.
Unfortunately, I've posted -- otherwise I would used my mod points to indicate this as a troll or overrated or something.
The two expressions are semantically identical. There is no difference between the two. So "any programmer" who sees a distinction between the two, is just a defective programmer. Just use the one that follows your "coding conventions" if you've got them, or just use the one you are used to.
This level of inane minutia is not what I would call "real programming", any more than typing skills are.
Most compilers today will get all the simple stuff like if (!ptr) vs if (NULL == ptr) optimization. Its the more complex things that the compiler cannot "prove" where it has trouble. For example:
void h(int x, int y) {
for (i=0; i < N; i++) {
if (0 != (x & (1 << y))) {
f(i);
} else {
g(i);
}
}
}
Very few compilers will dare simplify this to:
void h(int x, int y) {
if (0 != (x & (1 << y))) {
for (i=0; i < N; i++) f(i);
} else {
for (i=0; i < N; i++) g(i);
}
}
Because the compilers have a hard time realizing that the conditional is constant and should be hoisted to the outside of the for loop. The compiler has the opportunity to perform loop unrolling in the second form that its may not try in the first instance.
You can learn these things from experience, or you can simply figure it out for yourself with the afore mentioned decompilation tools.
Oh for crying out loud, can we please stop posting this "X-files" nonsense as if its for real? As if we don't have enough propaganda and lies being blasted our way in our media.
Look, we're talking about ESP. If you can't get James Randi to believe it, please don't bother us about it.
You know, of course, that the NSA did the same thing with SHA right? The original algorithm submitted was SHA-0, then the NSA recommended an unexplained minor change.
Last August SHA-0 was broken, so their tweak appears to have added about 6 months of extra life for SHA-1.
You simply have to model the the essential game state variables, then create a method for "serializing" them into something that can be thrown out to disk. There is no need at all for these variables to be global, just make sure you pass a "game context" down the call stack to any function which can modify the game state.
The reason why its important to have this abstraction, is that its required in order to make in-game demos, and to have any hope of writing a networked version of your game. It can also let you do strange things like split screen the game and let two people play independent games if you like (a speed contest, for example.)
Well completely automating it is probable not the right answer. Often people will submit a link to a .HTML page, which itself links to the larger file (like a movie) that causes their server to run out of bandwidth.
The Coral cache will only cache the top-most link -- and its actually left to the HTML author to coral cache the final contents. An example is a page I wrote here:
Thank you
The root html file is not cached at all, but its fairly small, so I'm not worried about it. All those pictures though? There ain't no way I would post such a link in slashdot if I had to pay for the bandwidth to serve up those pictures myself!
So this is really a message to HTML authors and slashdot story submitters.
Just create a raw typical URL for the thing, then write some HTML with the suffix: ".nyud.net:8090" on the end, and like magic you get free, virtually unlimited, and extremely reliable of bandwidth.
Read about the coral cache here.
This is a reply I sent to Seebach himself:
First, I will agree with the general premise that performance of systems has
not corresponded to the promise of Moore's law or other advertisements.
However, I have many disagreements with what has been written here.
- The corrollary of "component size" halving every 18 months (its actually
more like 20-24 months) is that the switching time is also correspondingly
reduced. This is what allows clock rates to increase in rough proportion to
Moore's law. So *YES* you should expect clock rates to improve as process
technology improves. Also, as component size decreases, the numer of
transistors that can be put into a given fixed size for a chip increases.
This gives designers more ability to create more sophisticated logic, or
simply increase cache sizes. So, besides expecting clock rate increases,
Moore's law suggests micro-architectural performance should also improve
over time.
- In the Windows world, anti-aliased fonts have been around since the mid to
late 90s and they have 0 impact on real performance. There is an ever so
slight complexity overhead in describing how the anti-aliasing occurrs, but
otherwise the operations are handled by the graphics driver and graphics
card. And in the Windows world, this and any other graphics operations
have been thoroughly scrutinized over the years by the massive amounts and
availability of graphics benchmarks. There is no monitor in existence that
can keep up with the raw pixel output performance of any graphics card
rendering any realistic amount of anti-aliased text -- i.e., there is no
way a human being could actually *see* the performance difference between
anti-aliased text or any other form of rendered text on a modern machine.
- As to the word processor -- most people turn off the paper clip and other
do-dads. And those who don't very rarely complain about the performance of
their machine. In the Windows world, on-the-fly WYSIWYG rendering has been
at realtime speeds since the early to mid 90s, which puts their
corresponding CPU clock rates at roughly the 50-100 Mhz range. Once again,
the vast availability of performance benchmarks has been a driving factor
in this. Automatic grammar and spell checkers run in the background --
i.e., they only use processor cycles that are not committed to more
important user feedback.
- Security of general software is about how well they have been designed and
how rigorously they have been tested. The comment about virus scanning
software is correct, however, many people do not *use* virus scanning
software (as is evidenced by the continued problem.) So this does not
explain the real performance issues.
- Program complexity is indeed at the heart of most of the problem, but you
have not clearly explained why. Most of these applications are written in
the C++ language. C++ is both a blessing and a curse, because it allows
developers to write far more sophisticated software (than in C) but unless
the developer is careful the penalty comes in performance. But the thing
about C++ is that its is almost always possible to recover all the
performance, if only enough examination and design of the critical paths is
done during development. In otherwords, in theory, there should be no
performance penalty for this more sophisticated software, but for some
reason there is.
My claim is the primary reason for this is the relative dearth of system
performance benchmarks. The only thing that motivates developers to improve
performance is if their customers complain -- that is, customers armed with
real numbers to back them up.
Since Ziff-Davis has pretty much gotten out of serious benchmarking in their
main magazine publications (except for video games) system/software
I worked for them in the mid 90s. I don't know what they do now, but back then they certainly did *NOT* do version control.
STREAM is not a real world app. Its just a massively parallel vector copy/sum/dot-product. Every SMP kernel in the world (even the older Linuxes) should be able to scale STREAM perfectly well.
The HPL results are more impressive, but keep in mind that linear equation solving code has advanced quite considerably (i.e., it tends to behave a lot like STREAM) to the point that its not very limited by kernel behavior.
No, he's referring to ALL video card vendors. I have worked for 2 different such companies, and I did this to drivers to make sure they passed WHQL, or tricked a benchmark or whatever.
The tone of the article almost has an edge of "I can't believe we do this in our industry I feel so dirty!" to it. The poster of the story is obviously some kind of new college hire or hasn't been in the industry for very long or something. All vendors do this, all the time. Its just the way it is.
Wait a second, wait a second. Consider the following code:
char md5_collision_play_area[2048] = {0};
if ((CRC16(md5_collision_play_area, 2048) & 1)) {
return goodApplication();
} else {
return Virus();
}
Ok, so now you apply the Wang et al. mechanism to start filling the md5_collision_play_area with stuff to find a collision pair. Then you have a 50% chance of finding a pair such that one version of the application runs the goodApplication() while the other runs Virus(). This means that on average, you have to run the collision construction mechanism twice before you get a pair that execute that condition with opposite results.
So then you publicize the file which runs the goodApplication() and publish the MD5 and advertise its functionality as the goodApplication() (which maybe you stole from somewhere.) Then one day you just switch it for its doppleganger (with the same MD5) which runs the virus version.
Is this not a way to exploit the MD5 weakness *today*?
- I have to second that. My feeling on it is when they had a meeting with a blank piece of paper to design this chip they only invited hardware people. All the tough stuff has been moved into software.
Here are some thoughts from a top Intel designer who left Intel