Any "standard" that requires specific hardware support is by its very nature a poor generic solution anyways. The future of PCs includes the OLPC and the EEE and things based on the nano or atom or whatever. A standard that requires performance not available to those kinds of machines is shooting itself in the foot.
I attended a lecture some years ago by a Microsoft employee who was high up in their security structure.
[...]
"Wrong! It is possible for a password policy to be TOO secure. Let me give you an example. It is possible to set up a security policy in NT that requires a password of at least 8 characters, which must also be mixed case, have at least one numerical digit, and at least one non-alphanumeric character, and which will require a change of password every week."
"As soon as you implement that policy, users will write their password on a post-it note, stick it to their monitor, and replace it with a new one every week. So you see, a password policy CAN be too secure for your own good."
This, by the way, *IS* the policy used internally at Microsoft.
That's the most ridiculous thing I have ever heard of.
Lines are *incredibly expensive*. Your screen cannot be expanded, the dot pitch cannot be improved, and your printer cannot ram 400 lines of text into a single sheet at a readable font.
The number of ergonomically useful vertical lines is essentially fixed. You can spend as much money as you like and you cannot realistically increase this.
Time is *NOT* wasted by brace hugging; more relevant lines of code can appear on the screen at once.
I don't even understand the argument for putting parentheses on their own line. It cannot be more readable except where its trading off screen space. With proper indenting, visually recognizing:
}
else
{
and
} else {
takes the same mental training and effort. The first just wastes additional LCD elements. As I explained to a former boss, I will use the "brace on its own line" coding convention if he buys me a 50" display upon which to read my code.
Readability has to be metered against "content per line read". The maintainability of code has nothing to do with how easily its read. It matters how much content can be understood with the same effort. Brace on its own line is a total loser on the measure.
This "lack of information" in poker is just a detail in the model of the game which makes the problem different and interesting. However, the process of making a poker-bot outplay a human is similar to what is doing in chess: convert brute force computational power into a solution to a decision making problem.
From a sequence of bets the bot must work out the probability of every possible hand his opponent might have that corresponds to that bet sequence, and compare it to its own hand, as well as the potential sequence of cards that might come up. Then the computer must estimate the effectiveness of each of its possible responses (call/check, raise, fold). Working out the exact odds is actually quite a difficult problem (from a bet sequence, to guessing the actual cards the opponent has), and thus Monte-Carlo methods may be used to estimate the odds. But you can always throw more computational horsepower at a Monte-Carlo simulation to get more accurate estimates.
The big difference between poker and chess, really, is that chess is a much *deeper* game than poker. When a top GM plays serious against a computer, s/he still has a chance because there is enough richness in the game to find very creative ideas that computers cannot calculate.
This can be difficult to understand unless you play chess seriously. But even as a moderate untitled player myself, I have managed to draw multiple times against Fritz 9.0 (who beat the World Champion in a match) by playing fortresses (creating locked pawns which prevent both sides from making progress regardless of material differences), playing convoluted repetitions, and reaching theoretically drawn endings even though I am material down (which the computer doesn't realize is a draw until too late). Top players can do what I do, only a lot better and more consistently, and find deeper ideas for actually winning games against the computer.
With computer poker I just don't see the same depth of complexity. Once you've worked out the odds and decided whether or not to bluff, semi-bluff or whatever, there just doesn't seem to be much else going on.
Sorry, my "sardonic emphasis filter" was not working correctly. I was implying that a woman making a few throwaway comments about such things *IS* the same thing as would be produced by a woman programmer who was charged with compiling statistics on the matter.
Congratulations, you've just entered at the top of my "most inane stuff I've heard all month" list.
Well I cannot but feel proud. Certainly your indignity is a sound rebuttal to my claim. You have indeed contributed to this discourse in a way that matches the substance of the original claims.
The question of why women don't do as well in higher level of academia or other technical fields is a relevant one, and I am very curious as to why nobody has made a real effort to look for the answer. The de facto response of women who perhaps find the question itself too threatening is to simply accuse men of repressing women into their lack of performance. And now having established that as the standard response they spin crap claims like this immune to any scrutiny because mouth breathers like you are only too willing to regurgitate the indignant stance. Yay for science.
As a male who tries to be as non-sexist as I can
Except for when you rant about how females can't compile proper statistics about female programmers, how females as a whole are an interest group, and imply that the average female programmer could not possibly be better than the average male programmer, despite the fact that programmers are a self-selected group to begin with and thus don't necessarily represent their gender at all.
Technically I've *responded* to the rantings of a female who is making ridiculous claims that are absurd in the extreme. But you just can't see that can you? Because you automatically give the woman making outrageous claims defending women a pass.
I probably generally write the best commented code of anyone I have ever worked with in my life
That reminds me of those studies which have shown that people will below-average knowledge are likely to overestimate their abilities, while people who actually know shit often end up being insecure because they are capable of seeing their own mistakes.
I'm sure it does. But if there were some *male* coder out there who happened to write really well commented code and stumble up on this utter nonsense of an article, how would you expect that person to respond?
Not to mention that, ignoring your subjective evaluation of your comments and accepting that you are the best commenter of all times, one outlier means jack shit.
Oh and this woman's ranting means more than jack shit? Perhaps you could explain yourself.
There's nothing in my brain that's being particularly female when I do this
So you constantly measure your oestrogen level?
The comments this woman made mean nothing at all. Maybe she's right, maybe she's wrong.
There's a much larger elephant in the room. Women barely code at all, let alone proficiently. To say that she's wrong doesn't even begin to characterize her nonsense. She's worse than wrong; she's on a totally different planet.
The same applies to your comments. You certainly said nothing that would invalidate anything this woman has said, and frankly, between the two of you, she seems to be slightly less insane.
Oh well, I'm glad you are measuring this in the appropriate way. Since she's less insane that I am, I suppose that's conclusive then!
I've worked with hundreds of people including a half dozen women. I've had occasion to examine their code, as well as that of others. There is no denying the evidence (there are fewer women coders and they don't excel). The real open question is how do you *explain* the evidence.
For people whose intent is just to take the standard politically correct "women are just as good as men at everything and even better where we've tricked them into not calling them on their bullshit" it may be impossible to see this objectively.
Sorry, my "sardonic emphasis filter" was not working correctly. I was implying that a woman making a few throwaway comments about such things *IS* the same thing as would be produced by a woman programmer who was charged with compiling statistics on the matter.
These things *are* study-worthy, but nobody bothers to actually do studies on it precisely because certain interest groups (that make up 51% of the population) aren't actually interested in the *real* answer for fear that it might be that programming or technical fields in general are just not ideally calibrated for women's brains.
As a male who tries to be as non-sexist as I can, I am interested in this problem as a way of understanding why there isn't more equality in this field; maybe there is something we can do about it, or maybe this has some value from a neuroscience point of view. But when the discourse is "women write better code because they have better comments" I just can't resist throwing a barb back in the other direction.
This is particularly infuriating for me, because I probably generally write the best commented code of anyone I have ever worked with in my life, and that includes the few females I have worked with. There's nothing in my brain that's being particularly female when I do this -- I think anyone who understands the issue of code maintenance knows the value of useful comments.
Seriously, how many women, percentage wise compared to men, are in the field? How can they come up with some stat that says women are better programmers if you've got (pulling number out of air) 1 woman to every 1000 men in the field? They hired a woman programmer to compile the statistics. I wish I were joking, but that's the only way garbage like this is ever claimed.
Personally, I have been very disappointed to learn that the few female programmers that I have encountered were significantly below par. But you don't see me making statistics out of that.
Interesting analogy, but you have not characterized the performance differences.
GPUs have totally pipelined and highly parallel ALU units available to it. Like 64 and 128-way parallelism on 4 channels at once. Compare this to an 8-way CPU system on 2-SIMD operands at once, at between 2 and 4 times the clock rate.
The other thing is that GPUs have special calculation ALUs that for doing multiple ops at once that are better designed than SSE-2 which is too primitive.
GPUs just win because they don't need to maintain backward compatibility or be designed for implementing databases.
Brian Hook is currently working on Duke Nukem Forever. I don't say that this guarantees it will ship, but at least Hook has a record of being able to ship projects.
So why did the binary program also have the password for the gmail account? One would assume that the email address would have been enough. After all, sending someone email doesn't require their password.
Because mail you send from gmail is also stored in your outbox. If you use gmail's POP3 features, that means that there is a race condition that can expose this hack to you before the program could even delete the incriminating evidence from your outbox. The malicious programmer in this case needed to store the information somewhere, where the original user would not, by default, see any trace of this information being passed around. Therefore it logged into an auxiliary account and probably do a "send to self" operation. There are other ways the programmer could have done this, but none would be nearly as cheap or easy to program while being "stealthy" (ignoring for the moment that this was actually discovered) as how it was done.
1) He made a movie about sweatshops: Nothing has been done to reduce the number of sweatshops. 2) He made a movie about gun violence in the US: There followed the Virginia Tech massacre. 3) He made a movie about 9/11 that indicts Bush for allowing it to happen: Bush was re-elected.
I can only assume that this movie fortells us of an America that will never receive universal health care of any kind.
No. What fucked-up animals a teeny minority of us are. Most of us are better than that. You are. I am.
These people don't live in isolation. People choose their behaviors as much as society does.
Let's give ourselves credit where it is deserved. There's probably not a person on this list who hasn't wanted to do multiple homicides now and then. But we don't. We learn to control our anger, to seek non-violent solutions.
Yes ok, and how many of us on this list has helped someone else who was having emotional difficulties? You want to pat yourself on the back because life's pressure doesn't exceed most people's ability to cope and most of us are in the majority?
Let's treat this incident as a baseline, and praise ourselves for having advanced well beyond it. This guy was an exception, not the norm.
I was a fledgling member of the CSC at Waterloo, and I recognize the members in the photos they showed. I also remember attending this talk with a front row seat. I was sort of unimpressed because he didn't discuss anything that was new or that I didn't already know about.
Unfortunately for Wendy Seltzer, YouTube is a completely incompetent and bad actor when it comes to censorship ( http://www.youtube.com/watch?v=By6aqz_79Uc ). She will have to go after YouTube, NFL *AND* the DMCA. She might be right, but the odds are stacked against her.
The writing in this story has got to be the worst, most horrendous writing of any technical story I have ever read in my life.
To summarize the *real* story as I know it so far, this lady (and her team) has weakened MD5, RIPEMD, and SHA-0 to the point of being useless (i.e., she is able to easily construct artificial collisions) in August of 2004. A year later in 2005, she showed that SHA-1 is significantly weaker than its advertised strength, however she did *NOT* fully weaken it (i.e., she, nor anyone else, has yet found a collision). It is widely assumed in the crypto community, however, that work along similar lines are likely to eventually weaken SHA-1 to the point of being as weak as SHA-0 is now. People like Bruce Schneier and others have already publically stated that we should stop using SHA-1 for any new algorithms. So it does not in any way surprise me that the Chinese government is going to stop using SHA-1 -- *EVERYONE* should stop using SHA-1 where it is possible. This is actually a real problem, BTW, since there are no well tested 160-bit secure hash algorithms available as substitute. The best candidate choices are things like Whirlpool (based on AES), but this algorithm has not been subjected to serious scrutiny yet. My personal preference, is to try to give myself some breathing room, and I've gone ahead and just shifted to 256 bits with SHA-256.
Now this piece of broken writing comes out. Can someone please tell me -- has Wang produced more results, or is this just a terribly written recap of events we are already aware of?
It helps if you follow a statement like this with something that isn't complete and utter bullshit.
Having a "far lower clock rate" isn't necessarily a weakness. Look at what AMD did when they dropped the gigahertz race and started giving the chips an arbitrary performance number.
Amd never dropped the gigahertz race. They simply continued on a less extreme curve than Intel. As we can see from Intel's latest generation of CPUs (which have even lower clock rate than AMD CPUs) the actual absolute numbers are artificial. The key point is that AMD's processors have continued to increase in clock rate on a regular basis. IBM spent years sitting on their G5 without ever reaching the covetted "3 Ghz" which Apple claims they promised.
Oh come on. Do you think the only thing that governs market success (and therefore also further R&D) is the quality of the product (Think Britney Spears)? x86 isn't a good arch. powerpc is.
So show be a side by side benchmark that isn't an utter lie (i.e., not something with Steve Jobs running the show.) Even on its merits as an instruction set architecture, the PowerPC is an utter embarassment. It has no per-address lock instructions and I described in my post, and they warp their micro-architecture by supporting a "store multiple" instruction. I.e., they are forced to do the equivalent of micro-code, like x86s do, without having the benefits of a rich instruction which exploits it. Because of its parsable variable length instruction encoding, x86s can add an arbitrary number of new instructions -- this allows them to add SSE, SSE-2, SSE-3, SSE-4 and so on. Because the PowerPC is a RISC, they have only a finite amount of space for their instructions, so they cannot keep adding in extensions like AltiVec-2, or anything like that.
No. They use good microarchitecture. X86 instructions do complicated things -- they are broken down, into simpler things, but not uniformly simpler things. For example, an x86 instruction can do a load, ALU then store -- the key point being that the address for the load and store being the same and therefore needs only be generated once. A RISC processor, since it would perform those three operations as seperate discrete instructions would be forced to generate the address twice (once for the load, then once for the store.) RISC processors usually only support the most basic minimal memory addressing capabilities -- usually 32bit aligned word accesses. An x86 can address various sizes straddling address boundaries at random. The x86 does break these down into two memory operations if need be, but the point is that this is determined at the time of execution, not by the compiler. There is also no serious penalty for doing things the x86 way, since the whole process is pipelined (there is at most a 1 cycle latency penalty.)
So its not a good characterization to say that x86 just uses RISC underneath. They do share some properties of some of the better RISC implementations (rename registers, large instruction windows, speculative execution, etc) but these are not properties particular to RISC.
bluefoxlucid asks: "With Apple having now switched to x86 CPUs, I've been wondering for a while why we use the x86 architecture at all...."
Because its a better CPU.
"... The Power architecture was known for its better performance per clock;..."
Utter nonsense. This is a complete lie. Benchmarks do not bear this out. And this is besides the fact, that this qualifier reveals the PowerPC's primary weakness -- it has a far lower clock rate.
"... and still other RISC architectures such as the various ARM models provide very high performance per clock as well as reduced power usage, opening some potential for low-power laptops.... "
ARM is currently made by Intel. It does have a high ops per clock performance, but it does so at a severe complexity penalty which drammatically limits clock rate. You can't get "free extra shift" or "free conditional computation" without some compromise to the architecture.
"... Compilers can also deal with optimization in RISC architectures more easily, since the instruction set is smaller and the possible scheduling arrangements are thus reduced greatly.... "
Nice in theory. Intel's latest generation compilers put other compilers to shame. Remember that x86s perform a lot of auto-scheduling themselves. While it may seem like putting more scheduling pressure onto the compiler seemed to make sense back in the 90s, no compiler can solve them totally correctly. This is critical especially in dynamic situations such as cache and branch misses (which the compiler can often neither detect or even solve). By letting the CPU solve the problem dynamically as the problems occurr, it can do so nearly optimally all the time.
"... With Just-in-Time compilation, legacy x86 programs could be painlessly run on ARM/PPC by translating them dynamically at run time, similar to how CIL and Java work.... "
Are you smoking pot? The state of the art in x86 CPU emulation are the Itanium and TransMeta CPUs. Both failed precisely because of their pathetic performance of their x86 emulators. The x86 has complicated addressing modes, flag registers, structured sub-registers, unaligned memory access, etc, which does not easily translate to "clean RISC" architectures. (However, they do translate to straight forward hardware implementations, as AMD and Intel have proven.)
"... So really, what do you all think about our choice of primary CPU architecture?... "
It is the correct and logical choice. If RISC were really the greatest thing since sliced bread, then PowerPC should be running circles around x86. But the truth is that it can't even keep up.
"... Are x86 and x86_64 a good choice; or should we have shot for PPC64 or a 64-bit ARM solution?"
Why would you want to use a slower, and less functional CPU? Yes, I said *LESS FUNCTIONAL*. Look into how the PowerPC performs atomic lock operations. Its pathetic. Its just built into the basic x86 architecture, but the PowerPC requires significant external hardware support (via special modes in the memory controller) to do the same thing. x86 just supports "locked memory addresses" which nicely maps to the caching modes.
PowerPC is missing both the right instructions and relevant memory semantics to support it directly. PowerPC uses seperate lock instructions for cache lines, which means that each thread can lock out other threads arbitrarily; if you crash or stall with a held lock, all dependent threads deadlock. It also means you can't put multiple locks in a single cache line and expect them to operate ind
It isn't an exact rendering of the code in question, but it explains enough for any skilled hacker to 1) understand what's going on and 2) modify the code to create the resulting code that's in the Quake 3 source. Furthermore this web page has existed since about 1997 (archive.org doesn't go back that far for some reason.)
Now *IF* in fact the code origin comes from someone who took ideas from my site, I should point out that *I* am not the originator of the idea either (though I did write the relevant code). Bruce Holloway (who I credit on the page) was the first person to point out this technique to me at around the 1997 timeframe (prior to this, I created my own method which is similar, but not really as fast). (Vesa Karvonen informed by of the technique (through a code snippet with no explanation) at roughly the same time as well.) It was a technique well known to hard core 3D accelerator and CPU implementors, and follows an intentional design idea from the IEEE-754 specification.
Prof. William Kahan, one of the key people who specified the IEEE-754 standard (the standard for floating point the many CPUs use, starting with Intel's 8087 coprocessor) apparently presented this idea, and is the source for where Bruce Holloway got the idea. The IEEE-754 standard came out around the 1982 time frame. Though, its very likely that these ideas originate from even earlier in computing history.
The problem is "I need to be able to have faith my ballot was counted properly, while being unable to prove to anyone (or have proven by anyone) that I voted a particular way".
You have solved nothing.
You have read nothing. If you actually read the material on the site you would realize that the protocol for counting the full result totals are also much more reliably done with this system, because the total counts become public information, rather than becoming proprietary counts held hostage in hackable memory cards, or suspicious central tabulators.
AMD should set their CPUID to "GenuineIntel". It's for interoperability grounds - Intel have shown they will use it to try and damage the performance of programs on AMD machines - so there shouldn't be any trademark issue, and it would stop this kind of crap once and for all.
1) AMD can't do this because some drivers may need to leverage/use HyperTransport features, and other processor-specific features, such a auto-clock throttling features when the processor overheats (SpeedStep? Cool'n'Quiet? PowerNow! -- whatever each vendor calls it.) So these drivers need CPUID to work properly. 2) AMD does do this in debug versions of their chip. However, these are not available for public consumption.
I did try ByteMark when Apple used it as a basis for it's claims, as I did with their other basis during other advertising campaigns over the years. When x86 ByteMark was compiled with a current compiler with appropriate settings the PowerPC improvements were far less dramatic than when Apple used an old 486 optimized version on a Pentium against a current PowerPC build.
And did you try ByteMark with a compiler built specifically for winning that benchmark on the x86? (Like the Intel Compiler?) Remember Apple quoted it, after taking whatever measures they wanted to to make sure they looked good on it. Intel responded many years later (they did not have a compiler shipping at the time Apple first used ByteMark publically), but only after Apple stopped using it as a benchmark. lmbench, which is a subset of the ByteMark benchmark for Linux systems, has been running for some time and show that x86 processors have been ahead of Mac processors from at least the time of the Athlon.
... Similar story when Apple used an inferior compiler for Intel spec scores, rather than official spec scores....
Which Spec scores? The recent stuff is fully debunked here: http://www.pobox.com/~qed/apple.html (scroll down a bit). Do you mean the old Spec 92 scores? If so, I just took the numbers from the Spec themselves -- Intel was mostly ahead of them (Motorola may have taken advantage of the lag in product launches between the Pentium and Pentium Pro to temporarily come out ahead).
Historically Apple's claims over the years have been marketing exaggerations, PowerPC turned out to only be slightly faster in technical comparisons but an overall loser in general real world comparisons.
There has never been any reputable numbers to back such a claim up. You have to go back to really old stuff before that is even possible.
You are mistaken regarding P3s and early Athlons. Are you playing games on the Athlon side where you use the actual clockrate rather than what AMD claims is the equivalent and uses on their product packaging and literature?
Its not likely that I would make that kind of mistake -- I used to work for an x86 vendor, and was following that stuff very closely at the time. The leading architecture of the PPC at the time was from Motorola, and the maximum potential of what the processor documentation said was lower than what the x86's of that same era actually delivered. The PowerPC G3 was basically comparable to the AMD K6 processor on a per-clock basis.
The G3 had fewer rename registers, the multistep single addressing modes common to most RISC processors, a non-fully pipelined floating point unit, two integer adder-ALUs, and very shallow speculation and reordering capabilities. The K6 had better reordering capabilities, but a slower instruction decoder. With the G4 the clock rate improved, and there was a slight increase in rename registers and reorder buffers, but the Athlon, P-III, and P4 all shipped during this period all of which had vastly superior microarchitectures (remember that these chips also all had hefty on-chip L2 caches).
The Motorola G4+ basically deepened the pipeline and increased the clock rate, but did something which dramatically lowered the IPC. I never bothered to figure out what that was since it was slower on clock rate anyways, and was clearly losing benchmarks even to the older G4.
It was not until the IBM 970 that the PPC was on a more even footing with x86s from an architectural point of view (deep pipelining, large reorder buffers, many rename registers, pipelined floating point, etc) -- except that they totally sacrificed integer performance. With a latency of 2 clocks per integer instruction, it meant that any code that has high integer utilization runs slower (some figures here:
Or perhaps you are having trouble with the word "generally" and didn't catch the clue that "Same story, year after year after year" indicates I am not discussing only the latest and greatest CPUs. I'm actually going back all the way to 603/604 days.
Its been true since the Athlon/Pentium III days. Before that there were no benchmarks on the Power PC at all (you're not going to bring up ByteMark are you?), and thus you have no basis at all to make such a claim.
(*) Yes, I know that for PowerPC and Intel of the *same clockrate* PowerPC is generally 25-30% faster, the problem is PowerPC's perpetual lower clockrates.
This is actually *NOT TRUE*, and your repetition of it is testimony to the effectiveness of Jobs' reality distortion field. Especially the latest generation of PowerPCs -- Athlon/Opteron and now the new Pentium-M based CPUs all have tremendously highly *PER CLOCK* performance (this due in large part to IBM's decision to go with 2-cycle latency integer instructions). So the total gap in performance is *MUCH* higher than people's perceptions about it.
Slashdot Mirror
Any "standard" that requires specific hardware support is by its very nature a poor generic solution anyways. The future of PCs includes the OLPC and the EEE and things based on the nano or atom or whatever. A standard that requires performance not available to those kinds of machines is shooting itself in the foot.
I attended a lecture some years ago by a Microsoft employee who was high up in their security structure.
[...]
"Wrong! It is possible for a password policy to be TOO secure. Let me give you an example. It is possible to set up a security policy in NT that requires a password of at least 8 characters, which must also be mixed case, have at least one numerical digit, and at least one non-alphanumeric character, and which will require a change of password every week."
"As soon as you implement that policy, users will write their password on a post-it note, stick it to their monitor, and replace it with a new one every week. So you see, a password policy CAN be too secure for your own good."
This, by the way, *IS* the policy used internally at Microsoft.
That's the most ridiculous thing I have ever heard of.
Lines are *incredibly expensive*. Your screen cannot be expanded, the dot pitch cannot be improved, and your printer cannot ram 400 lines of text into a single sheet at a readable font.
The number of ergonomically useful vertical lines is essentially fixed. You can spend as much money as you like and you cannot realistically increase this.
Time is *NOT* wasted by brace hugging; more relevant lines of code can appear on the screen at once.
Mod parent up.
I don't even understand the argument for putting parentheses on their own line. It cannot be more readable except where its trading off screen space. With proper indenting, visually recognizing:
}
else
{
and
} else {
takes the same mental training and effort. The first just wastes additional LCD elements. As I explained to a former boss, I will use the "brace on its own line" coding convention if he buys me a 50" display upon which to read my code.
Readability has to be metered against "content per line read". The maintainability of code has nothing to do with how easily its read. It matters how much content can be understood with the same effort. Brace on its own line is a total loser on the measure.
This "lack of information" in poker is just a detail in the model of the game which makes the problem different and interesting. However, the process of making a poker-bot outplay a human is similar to what is doing in chess: convert brute force computational power into a solution to a decision making problem.
From a sequence of bets the bot must work out the probability of every possible hand his opponent might have that corresponds to that bet sequence, and compare it to its own hand, as well as the potential sequence of cards that might come up. Then the computer must estimate the effectiveness of each of its possible responses (call/check, raise, fold). Working out the exact odds is actually quite a difficult problem (from a bet sequence, to guessing the actual cards the opponent has), and thus Monte-Carlo methods may be used to estimate the odds. But you can always throw more computational horsepower at a Monte-Carlo simulation to get more accurate estimates.
The big difference between poker and chess, really, is that chess is a much *deeper* game than poker. When a top GM plays serious against a computer, s/he still has a chance because there is enough richness in the game to find very creative ideas that computers cannot calculate.
This can be difficult to understand unless you play chess seriously. But even as a moderate untitled player myself, I have managed to draw multiple times against Fritz 9.0 (who beat the World Champion in a match) by playing fortresses (creating locked pawns which prevent both sides from making progress regardless of material differences), playing convoluted repetitions, and reaching theoretically drawn endings even though I am material down (which the computer doesn't realize is a draw until too late). Top players can do what I do, only a lot better and more consistently, and find deeper ideas for actually winning games against the computer.
With computer poker I just don't see the same depth of complexity. Once you've worked out the odds and decided whether or not to bluff, semi-bluff or whatever, there just doesn't seem to be much else going on.
Congratulations, you've just entered at the top of my "most inane stuff I've heard all month" list.
Well I cannot but feel proud. Certainly your indignity is a sound rebuttal to my claim. You have indeed contributed to this discourse in a way that matches the substance of the original claims.The question of why women don't do as well in higher level of academia or other technical fields is a relevant one, and I am very curious as to why nobody has made a real effort to look for the answer. The de facto response of women who perhaps find the question itself too threatening is to simply accuse men of repressing women into their lack of performance. And now having established that as the standard response they spin crap claims like this immune to any scrutiny because mouth breathers like you are only too willing to regurgitate the indignant stance. Yay for science.
Except for when you rant about how females can't compile proper statistics about female programmers, how females as a whole are an interest group, and imply that the average female programmer could not possibly be better than the average male programmer, despite the fact that programmers are a self-selected group to begin with and thus don't necessarily represent their gender at all.
Technically I've *responded* to the rantings of a female who is making ridiculous claims that are absurd in the extreme. But you just can't see that can you? Because you automatically give the woman making outrageous claims defending women a pass.That reminds me of those studies which have shown that people will below-average knowledge are likely to overestimate their abilities, while people who actually know shit often end up being insecure because they are capable of seeing their own mistakes.
I'm sure it does. But if there were some *male* coder out there who happened to write really well commented code and stumble up on this utter nonsense of an article, how would you expect that person to respond?Not to mention that, ignoring your subjective evaluation of your comments and accepting that you are the best commenter of all times, one outlier means jack shit.
Oh and this woman's ranting means more than jack shit? Perhaps you could explain yourself.So you constantly measure your oestrogen level?
The comments this woman made mean nothing at all. Maybe she's right, maybe she's wrong.
There's a much larger elephant in the room. Women barely code at all, let alone proficiently. To say that she's wrong doesn't even begin to characterize her nonsense. She's worse than wrong; she's on a totally different planet.The same applies to your comments. You certainly said nothing that would invalidate anything this woman has said, and frankly, between the two of you, she seems to be slightly less insane.
Oh well, I'm glad you are measuring this in the appropriate way. Since she's less insane that I am, I suppose that's conclusive then!I've worked with hundreds of people including a half dozen women. I've had occasion to examine their code, as well as that of others. There is no denying the evidence (there are fewer women coders and they don't excel). The real open question is how do you *explain* the evidence.
For people whose intent is just to take the standard politically correct "women are just as good as men at everything and even better where we've tricked them into not calling them on their bullshit" it may be impossible to see this objectively.
Sorry, my "sardonic emphasis filter" was not working correctly. I was implying that a woman making a few throwaway comments about such things *IS* the same thing as would be produced by a woman programmer who was charged with compiling statistics on the matter.
These things *are* study-worthy, but nobody bothers to actually do studies on it precisely because certain interest groups (that make up 51% of the population) aren't actually interested in the *real* answer for fear that it might be that programming or technical fields in general are just not ideally calibrated for women's brains.
As a male who tries to be as non-sexist as I can, I am interested in this problem as a way of understanding why there isn't more equality in this field; maybe there is something we can do about it, or maybe this has some value from a neuroscience point of view. But when the discourse is "women write better code because they have better comments" I just can't resist throwing a barb back in the other direction.
This is particularly infuriating for me, because I probably generally write the best commented code of anyone I have ever worked with in my life, and that includes the few females I have worked with. There's nothing in my brain that's being particularly female when I do this -- I think anyone who understands the issue of code maintenance knows the value of useful comments.
Personally, I have been very disappointed to learn that the few female programmers that I have encountered were significantly below par. But you don't see me making statistics out of that.
Interesting analogy, but you have not characterized the performance differences.
GPUs have totally pipelined and highly parallel ALU units available to it. Like 64 and 128-way parallelism on 4 channels at once. Compare this to an 8-way CPU system on 2-SIMD operands at once, at between 2 and 4 times the clock rate.
The other thing is that GPUs have special calculation ALUs that for doing multiple ops at once that are better designed than SSE-2 which is too primitive.
GPUs just win because they don't need to maintain backward compatibility or be designed for implementing databases.
Brian Hook is currently working on Duke Nukem Forever. I don't say that this guarantees it will ship, but at least Hook has a record of being able to ship projects.
Influential?!?! Wait a second:
1) He made a movie about sweatshops: Nothing has been done to reduce the number of sweatshops.
2) He made a movie about gun violence in the US: There followed the Virginia Tech massacre.
3) He made a movie about 9/11 that indicts Bush for allowing it to happen: Bush was re-elected.
I can only assume that this movie fortells us of an America that will never receive universal health care of any kind.
I was a fledgling member of the CSC at Waterloo, and I recognize the members in the photos they showed. I also remember attending this talk with a front row seat. I was sort of unimpressed because he didn't discuss anything that was new or that I didn't already know about.
Unfortunately for Wendy Seltzer, YouTube is a completely incompetent and bad actor when it comes to censorship ( http://www.youtube.com/watch?v=By6aqz_79Uc ). She will have to go after YouTube, NFL *AND* the DMCA. She might be right, but the odds are stacked against her.
The writing in this story has got to be the worst, most horrendous writing of any technical story I have ever read in my life.
To summarize the *real* story as I know it so far, this lady (and her team) has weakened MD5, RIPEMD, and SHA-0 to the point of being useless (i.e., she is able to easily construct artificial collisions) in August of 2004. A year later in 2005, she showed that SHA-1 is significantly weaker than its advertised strength, however she did *NOT* fully weaken it (i.e., she, nor anyone else, has yet found a collision). It is widely assumed in the crypto community, however, that work along similar lines are likely to eventually weaken SHA-1 to the point of being as weak as SHA-0 is now. People like Bruce Schneier and others have already publically stated that we should stop using SHA-1 for any new algorithms. So it does not in any way surprise me that the Chinese government is going to stop using SHA-1 -- *EVERYONE* should stop using SHA-1 where it is possible. This is actually a real problem, BTW, since there are no well tested 160-bit secure hash algorithms available as substitute. The best candidate choices are things like Whirlpool (based on AES), but this algorithm has not been subjected to serious scrutiny yet. My personal preference, is to try to give myself some breathing room, and I've gone ahead and just shifted to 256 bits with SHA-256.
Now this piece of broken writing comes out. Can someone please tell me -- has Wang produced more results, or is this just a terribly written recap of events we are already aware of?
It helps if you follow a statement like this with something that isn't complete and utter bullshit.
Amd never dropped the gigahertz race. They simply continued on a less extreme curve than Intel. As we can see from Intel's latest generation of CPUs (which have even lower clock rate than AMD CPUs) the actual absolute numbers are artificial. The key point is that AMD's processors have continued to increase in clock rate on a regular basis. IBM spent years sitting on their G5 without ever reaching the covetted "3 Ghz" which Apple claims they promised.
So show be a side by side benchmark that isn't an utter lie (i.e., not something with Steve Jobs running the show.) Even on its merits as an instruction set architecture, the PowerPC is an utter embarassment. It has no per-address lock instructions and I described in my post, and they warp their micro-architecture by supporting a "store multiple" instruction. I.e., they are forced to do the equivalent of micro-code, like x86s do, without having the benefits of a rich instruction which exploits it. Because of its parsable variable length instruction encoding, x86s can add an arbitrary number of new instructions -- this allows them to add SSE, SSE-2, SSE-3, SSE-4 and so on. Because the PowerPC is a RISC, they have only a finite amount of space for their instructions, so they cannot keep adding in extensions like AltiVec-2, or anything like that.
No. They use good microarchitecture. X86 instructions do complicated things -- they are broken down, into simpler things, but not uniformly simpler things. For example, an x86 instruction can do a load, ALU then store -- the key point being that the address for the load and store being the same and therefore needs only be generated once. A RISC processor, since it would perform those three operations as seperate discrete instructions would be forced to generate the address twice (once for the load, then once for the store.) RISC processors usually only support the most basic minimal memory addressing capabilities -- usually 32bit aligned word accesses. An x86 can address various sizes straddling address boundaries at random. The x86 does break these down into two memory operations if need be, but the point is that this is determined at the time of execution, not by the compiler. There is also no serious penalty for doing things the x86 way, since the whole process is pipelined (there is at most a 1 cycle latency penalty.)
So its not a good characterization to say that x86 just uses RISC underneath. They do share some properties of some of the better RISC implementations (rename registers, large instruction windows, speculative execution, etc) but these are not properties particular to RISC.
Because its a better CPU.
Utter nonsense. This is a complete lie. Benchmarks do not bear this out. And this is besides the fact, that this qualifier reveals the PowerPC's primary weakness -- it has a far lower clock rate.
ARM is currently made by Intel. It does have a high ops per clock performance, but it does so at a severe complexity penalty which drammatically limits clock rate. You can't get "free extra shift" or "free conditional computation" without some compromise to the architecture.
Nice in theory. Intel's latest generation compilers put other compilers to shame. Remember that x86s perform a lot of auto-scheduling themselves. While it may seem like putting more scheduling pressure onto the compiler seemed to make sense back in the 90s, no compiler can solve them totally correctly. This is critical especially in dynamic situations such as cache and branch misses (which the compiler can often neither detect or even solve). By letting the CPU solve the problem dynamically as the problems occurr, it can do so nearly optimally all the time.
Are you smoking pot? The state of the art in x86 CPU emulation are the Itanium and TransMeta CPUs. Both failed precisely because of their pathetic performance of their x86 emulators. The x86 has complicated addressing modes, flag registers, structured sub-registers, unaligned memory access, etc, which does not easily translate to "clean RISC" architectures. (However, they do translate to straight forward hardware implementations, as AMD and Intel have proven.)
It is the correct and logical choice. If RISC were really the greatest thing since sliced bread, then PowerPC should be running circles around x86. But the truth is that it can't even keep up.
Why would you want to use a slower, and less functional CPU? Yes, I said *LESS FUNCTIONAL*. Look into how the PowerPC performs atomic lock operations. Its pathetic. Its just built into the basic x86 architecture, but the PowerPC requires significant external hardware support (via special modes in the memory controller) to do the same thing. x86 just supports "locked memory addresses" which nicely maps to the caching modes.
PowerPC is missing both the right instructions and relevant memory semantics to support it directly. PowerPC uses seperate lock instructions for cache lines, which means that each thread can lock out other threads arbitrarily; if you crash or stall with a held lock, all dependent threads deadlock. It also means you can't put multiple locks in a single cache line and expect them to operate ind
Here's an old version of one of my webpages:
c ities.com/SiliconValley/9498/sqroot.html
http://web.archive.org/web/19990210111728/www.geo
And here's an updated version of the same page:
http://www.azillionmonkeys.com/qed/sqroot.html
It isn't an exact rendering of the code in question, but it explains enough for any skilled hacker to 1) understand what's going on and 2) modify the code to create the resulting code that's in the Quake 3 source. Furthermore this web page has existed since about 1997 (archive.org doesn't go back that far for some reason.)
Now *IF* in fact the code origin comes from someone who took ideas from my site, I should point out that *I* am not the originator of the idea either (though I did write the relevant code). Bruce Holloway (who I credit on the page) was the first person to point out this technique to me at around the 1997 timeframe (prior to this, I created my own method which is similar, but not really as fast). (Vesa Karvonen informed by of the technique (through a code snippet with no explanation) at roughly the same time as well.) It was a technique well known to hard core 3D accelerator and CPU implementors, and follows an intentional design idea from the IEEE-754 specification.
Prof. William Kahan, one of the key people who specified the IEEE-754 standard (the standard for floating point the many CPUs use, starting with Intel's 8087 coprocessor) apparently presented this idea, and is the source for where Bruce Holloway got the idea. The IEEE-754 standard came out around the 1982 time frame. Though, its very likely that these ideas originate from even earlier in computing history.
The problem is "I need to be able to have faith my ballot was counted properly, while being unable to prove to anyone (or have proven by anyone) that I voted a particular way".
You have solved nothing.
You have read nothing. If you actually read the material on the site you would realize that the protocol for counting the full result totals are also much more reliably done with this system, because the total counts become public information, rather than becoming proprietary counts held hostage in hackable memory cards, or suspicious central tabulators.
2) AMD does do this in debug versions of their chip. However, these are not available for public consumption.
And did you try ByteMark with a compiler built specifically for winning that benchmark on the x86? (Like the Intel Compiler?) Remember Apple quoted it, after taking whatever measures they wanted to to make sure they looked good on it. Intel responded many years later (they did not have a compiler shipping at the time Apple first used ByteMark publically), but only after Apple stopped using it as a benchmark. lmbench, which is a subset of the ByteMark benchmark for Linux systems, has been running for some time and show that x86 processors have been ahead of Mac processors from at least the time of the Athlon.
Which Spec scores? The recent stuff is fully debunked here: http://www.pobox.com/~qed/apple.html (scroll down a bit). Do you mean the old Spec 92 scores? If so, I just took the numbers from the Spec themselves -- Intel was mostly ahead of them (Motorola may have taken advantage of the lag in product launches between the Pentium and Pentium Pro to temporarily come out ahead).
There has never been any reputable numbers to back such a claim up. You have to go back to really old stuff before that is even possible.
Its not likely that I would make that kind of mistake -- I used to work for an x86 vendor, and was following that stuff very closely at the time. The leading architecture of the PPC at the time was from Motorola, and the maximum potential of what the processor documentation said was lower than what the x86's of that same era actually delivered. The PowerPC G3 was basically comparable to the AMD K6 processor on a per-clock basis.
The G3 had fewer rename registers, the multistep single addressing modes common to most RISC processors, a non-fully pipelined floating point unit, two integer adder-ALUs, and very shallow speculation and reordering capabilities. The K6 had better reordering capabilities, but a slower instruction decoder. With the G4 the clock rate improved, and there was a slight increase in rename registers and reorder buffers, but the Athlon, P-III, and P4 all shipped during this period all of which had vastly superior microarchitectures (remember that these chips also all had hefty on-chip L2 caches).
The Motorola G4+ basically deepened the pipeline and increased the clock rate, but did something which dramatically lowered the IPC. I never bothered to figure out what that was since it was slower on clock rate anyways, and was clearly losing benchmarks even to the older G4.
It was not until the IBM 970 that the PPC was on a more even footing with x86s from an architectural point of view (deep pipelining, large reorder buffers, many rename registers, pipelined floating point, etc) -- except that they totally sacrificed integer performance. With a latency of 2 clocks per integer instruction, it meant that any code that has high integer utilization runs slower (some figures here: