Most North American sports fans I know assume cycling is just a test of physical fitness, comparable to competitive marathon or track and field. Not so. Drafting in cycling is crucial; at the speeds the pros race, sitting on another rider's wheel saves about 40% in power compared to riding into the wind. Team strategy and tactics more often determine winners than raw fitness.
It's funny that NASCAR and pro cycling occupy almost opposite public images in the North American gestalt: hirsute, homegrown, working class sport vs. effete, Euro, vaguely yuppie-ish sport. But the sports' underlying structures (strategy, tactics, etc.) are surjective.
Do anybody else's eyes glaze over whenever Slashdot posts an "X, Y, and Z," article?
Memetics, the law, and intrusion detection.
Nutrition, Dianetics, and your urinary tract.
Perl, selfishness, and the Law of Large Numbers.
Veganism, modernity, and the DMCA.
I just made those up, but do you see how annoying it is? The "X, Y, and Z" title format is naturally grandiose; it says to the reader, "Brace yourself! The following incredible story will arc from X, to Y, and then all the way over to Z!"
Perhaps if employed less sparingly, the "X, Y, and Z" title format could be effective, but this being slashdot, it rarely delivers on its promise. When I see a slashdot article in this format, I know that the actual story will be about some lawsuit which pertains directly to Z, but only tangentially relates to X or Y.
On the one hand... VMWare supports specific OSes, not just any x86 OS. So one wonders how complete their virtualization is.
Wrongo. When we say "VMware supports FreeBSD," we mean that customers can call us and expect us to help with problems running FreeBSD in a VM. "Unsupported" guests that work fine include Plan9, BeOS, Openstep, FreeDOS, and AtheOS. VMware is not just a big dumb hack that happens to work for Linux and Windows.
I work for VMware. if you want to believe we've corrupted Kevin's precious bodily fluids, feel free. I don't speak for the company, and I know nothing beyond what slashdot has posted about plex86. Consider yourself disclaimed.
If I understand the story correctly, plex86 has basically surrendered. They've given up on running arbitrary supervisor level code; the Linux guests that Kevin refers to above require a patch to "fix" something the new "lean, mean" plex86 gets wrong.
If Linus is feeling even vaguely himself, he will not accept this patch. Ordinarily, people trying to put stuff into the kernel that a) hurts performance, and b) fixes no real problem, but c) is critical to some contrived project that seems really important to the contributor get entertainingly flamed, and then shown the door. In fact, Kevin's most likely motivation for submitting this as a Slashdot story is to marshall support for his Linux patch.
Even if Linus does accept this patch, I can guarantee you that Microsoft, the FreeBSD team, the now non-existent Be, etc., won't all be taking helpful hints from Kevin about which x86 features they may and may not use. Ergo, there is nothing interesting (either commercially or geekily) you can do with plex86; the most it can hope for is to run recent-ish Linux guests on recent-ish Linux hosts. Bestill my heart.
On the upside, maybe Kevin will stop implying that VMware stole Bochs, now that he's spent four years trying to clone our software and has finally admitted defeat.
Why must a gender difference be evidence of overt or covert discrimination? In my opinion, the CS gender differential comes from differences in hardware, rather than software. Drop me in the "nature" bin on this question: I think that women, on average, differ from men in such a way that they are less likely to be interested in computer science. I could get into why I believe this, but it's all anecdotal, and wouldn't convince anybody who didn't already agree with me.
Note that this in no way justifies discrimination against women. This discrimination is still clearly a reality, and must ultimately be eradicated root and branch. It is wrong to prejudge individuals by the group they belong to, not, as extreme "nurturists" would hold, because there are no differences among groups, but because respect for ones fellow humans requires that we treat them as equals. I.e., equality of opportunity is a matter of ethics, and ethical principles shouldn't be held hostage to questions of animal biology.
For those who wish to wring their hands about this gender discrepancy, must every field be split, 50/50 (well, 51/49)? Is the only possible "just" society one where soldiers, professional athletes, nurses, artists, even rapists, thieves and murderers, are exactly as likely to be male as female? What if the average woman doesn't care very much about computers, or artillery, or how to hotwire cars, not because of Barbie, or because their math teacher didn't call on them in seventh grade, but because she simply finds other things more interesting? If such women exist, discrimination "on behalf" of women in many male-dominated fields would ultimately make women less happy. It would, by definition, divert women who would otherwise be happier doing something else into male-dominated careers, to satisfy some sort of mathematical imperative of justice.
That is why I'm very leary of those who would rush to affirmative action-ize CS. You might not side with me on the "nature" side of this question; but regardless, I think the nature/nurture debate in this case is too far from resolution to be sure whether such programs are a net benefit or harm to womankind.
Intel has a very strong history of designing chips that ramp up very well (except for their one CPU engineering failure, the Pentium Pro, which was too ambitiously designed).
While your overall thesis is correct, your parenthetical diss of the PPro is ass-backwards. The PPro core is the same core that has been tweaked into the PIII. It had an approximately seven-year productive span, during which it was very competitive, although it was considered a monstrosity in its original incarnation as the Pentium Pro. I.e., the PPro is exhibit A in your argument, not some sort of exception to be excused.
Re:Just to remind people why more bits is good..
on
AMD's 64-bit Plot
·
· Score: 3, Informative
Servers have already hit this limit. That's why there are special instructions (a return to segmented memory access) on P3 and P4 processors, allowing up to 64gb of RAM in 4gb segments to be addressed.
Bzzt. The feature you're describing is known as PAE, for physical address extension. It doesn't work via "real mode" style DOS segmentation. Each program's virtual address space is still 4GB, and pointers are still a flat 32 bits. PAE simply changes the hardware page table structure so the 4GB "window" of your virtual address space can look out onto more than 4GBs of physical memory. Even though no one process can access more memory than before, you can run multiple, 4GB processes on a single machine.
Miraculously, someone at Intel stowed the x86 crackpipe, preventing some sort of segmented/overlay nightmare like the one you describe.
Reading the paper, I get the impression that this is mostly typical undergraduate hand-wringing about the gulf between academia and industry. That's fine, as far as it goes, and I've certainly indulged in my fair share of it. However, as an occasional student of stuff other than computer science, I'm a bit worried by their choice of terminology.
To sum up: Post-freaking-modernism??? Do these people have any idea what a plague on the humanities the loose collection of intellectual conceits known as "postmodernism" has been?
I've tried my hand at reading Foucault/Derrida/Barthes/etc., and their secondary sources. It's exceptionally difficult, but not in the way that, say, a complex algorithm is difficult. It's difficult in the way religious texts, or David Lynch movies are difficult; i.e., the difficulty is a smokescreen to keep the reader from catching on that this is all a bunch of bullshit.
This sort of deal typically begins with, "I will argue that {truth,reason,science,gender} is {non-existent,socially constructed,a masculinist plot}." Several hundred extraordinarily poorly written pages follow in which the author, in varying degrees of good faith, actually tries to argue these points. Of course, if truth is socially constructed, we all have no basis upon which to discuss anything. Rather than calling one another on it, the postmodernists collectively wink at one another, and promise to take one another seriously, and quote one another every chance they get. It's academics by pyramid scheme.
I understand why humanities people, even bright ones, fall for this routine, since they might go through all of their undergraduate and graduate education without encountering a single academic who hasn't drunk from postmodernism's poisoned cup; but why on earth would computer scientists be visiting this curse on a journal I subscribe to?
To those posters above tempted to give in to the siren song of self-referentiality, who might be thinking, "Hey, some of my CS classes are boring, maybe we need some of this radical 'postmodern' stuff to kick boring old CS in the pants," remember: computer science is very, very young. New ideas and techniques are thick on the ground in fields as diverse as graphics, systems, theory, AI, and software engineering. Literary critics eventually turned to postmodernism in part because it seemed like there was nothing left to say, and this postmodernism stuff, bullshit or not, was at least different. In computer science, we are still learning how to write a well-structured novel.
VMware is a bit of a special case, because it's inordinately difficult to clone. Had the plex86 project been successful, very few individual Linux users would be buying VMware Workstation. Even still, for months in 1999 the top few google hits on "vmware" were sites with pirated serial numbers.
(On most Linux boxes, stacks grow towards lower addresses, except on Alpha, IIRC. Heaps depend on the libc implementation, not the CPU.)
Nope. At the time I was doing the i960 port of ucLinux, I had to teach Linux to handle stacks growing towards higher addresses. The kernel stack overflow checking code would unconditionally look at the low end of the kernel stack; on i960, it was necessary to look at the high end. This was in 1998, eons after the alpha port had been integrated. Since then, the pa-risc port has also had to cope with "backwards" stacks, and it wouldn't surprise me if some of the goofball architectures (like SuperH) had strange stacks too.
Note that having stacks grow towards higher addresses doesn't cure buffer overflows. It sounds promising; how will you overflow a string to write over a return address if the return address is at a lower virtual address than the string? But architectures like i960 and pa-risc are still vulnerable, because sometimes stack buffers are passed to called functions. If you can coerce the called function into overflowing its caller's buffer, you can overwrite the called function's activation record. It's a bit trickier, but still possible.
Actually, I am looking forward to the 3ghz since I've heard, well, rumours that Intel is enabling SMT on it.
SMT has been quietly enabled for Xeon P4's for some time. If your BIOS is capable of preparing an MP spec for the SMT P4's, you can run commodity OS'es with "virtual" processor counts higher than your physical processor count today.
Second of all, intel stretched their pipeline to 40+ stages, this means that the penalty for pipeline stall, branch perdiction miss, context switch, etc is *HUGE*. AMD's Athlon pipeline was a lean 7 stages.
Nicely confabulated! When making stuff up to prove a point, you might as well go for the jugular. The pipeline lengths in question are 20 and 10, not 40 and 7. Incidentally, a long pipeline has nearly nothing to do with "context switch", at least as that term is commonly used (i.e., switching from one process context to another). Any pipeline issues caused by a context switch are dwarfed a thousand times over by cache and TLB issues.
Aside: what is with the short pipeline fetishism on the part of AMD partisans? You guys realize that they had four- and fiv-stage implementations of MIPS CPUs back in the early '80's, right? Imagine how brilliantly fast a MIPS r2000 would be in 3.0GHz! Oh, wait, you can't make an r2000 run at that clock speed. Hmm. Maybe pipeline length is just one parameter in a complicated design space, and we should look on manufacturer variations as differing technical solutions. After all, that's how we treat cache design, functional unit choices, and myriad other microarchitectural parameters.
No, that sounds complicated. It must be an Intel conspiracy to corrupt our precious bodily fluids...
Why did Intel do this? They were scared because AMD beat them at their own game.
Then in a few sentences, you say:
You'll notice now that Intels best P4 is faster then AMD's best part right now...
Umm, so how was Intel "beaten at its own game"? A bit of history, for perspective.
The Pentium III is the same core that was originally sold as the Pentium Pro. That core was introduced in 1995, and Intel is still squeezing performance out of it. At the beginning of the PPro's lifetime, it was an extremely ambitious design for the physical processes then available; people called it a too-hot, too-big, too-transistor-intensive monstrosity that would never be practical. Towards the middle of its life, in the years '97 to 2000 or so, the PIII was nicely matched to the physical parameters of then-current fab technology, and Intel produced modest shrinks and speed bumps seemingly at will. Those were the salad years of the PIII. Now physical technology has moved further down the road, and the PPro core is showing its age. It's leaving performance on the table that could be scooped up with transistor-intensive techniques like trace caches, more functional units, issue width, etc.
Like almost every other design generation of every CPU, ever, the P4 has a more complicated pipeline than its predecssors. Just as in 1995, the first year showed pretty "meh" performance, with much armchair punditry claiming that it's a monstrosity. Now, about 18 months after its introduction, the P4 is scaling well. AMD, on the other hand, is struggling to wring a few more modest speed bumps out of the K7 before it limps along to the end of its design life. The AMD partisans hold out hope for the K8, generally forgetting that the K8 is a K7 with a 64-bit bag on the side.
It saddens me to type this on my Athlon, but there's a strong likelihood that AMD's years in the sun are over. Five years hence, we might be looking back at the years 1999-2001 as a lost golden age of competition in the x86 CPU space.
To remedy the situation, processors ratings need to be measured in IPC*MHZ [instructions per cycle] for both integer and floating point operations. Then it would be pretty clear to consumers what was going on.
Any simple attempt at measuring performance will end up being simplistic. The big problem with your proposal can be summed up as: which instructions? NOPs? SIMD floating point? The instructions that make up Quake III, or gcc, or my LISP stock market prediction application? What about when the instruction sets of the CPUs differ, ala SSE2? Performance characterization really is difficult; anybody who claims otherwise is trying to sell you something.
ofcourse. that however, is a clever hack. not a fix.
Umm, safe mode is the documented, standard way of fixing fatal driver problems with windows. There's nothing "clever" or "hacky" about it. You claimed windows refused to boot in VGA mode, and grandparent pointed out that this was because you are ignorant. Thank the man and move along.
No, it's a major advance in instruction decoding. Conventional IA-32 decoders are hardwired into transistors. They do perform extremely well, but at a very high cost in power and die area, and because they're hardwired it's difficult to design complex behavior.
The Pentium 4's trace cache solves most of the headaches of IA32 decoding, for a meaninglessly small fraction of the effort of Transmeta's solution. Seems a bit more effective way of solving the problem than inventing a new implementation technique and doing the equivalent of a dozen or so PhD theses making it work, don't you think?
This whole "code-morphing is for power saving" line is a rather transparent rewriting of history on the part of Transmeta. At the time of Transmeta's founding, they clearly hoped that transparent, online software optimization would be so effective that they'd produce a much faster x86 than is otherwise possible. When it became clear that they'd underestimated x86 performance curves, they needed some reason for having spent all that money on Linus's salary. An almost random implementation side effect happened to consume less power than other x86 CPUs; so, the fiction that the world was clamoring for fractionally lower-power x86 cpus than are available from its competitors was invented.
I don't have any sort of privileged information about this; it just seems to fit the data well. How would a company whose business model is Transmeta's current one ever get founded, given that it involves two leaps of faith: first, that people want to buy low-power x86'es, and second, that this "code-morphing" jiggery-pokey will actually produce a low-power x86. It would be much easier to get started on the assumption that these things would actually be fast (which they clearly hoped), since there's a proven market for fast CPUs.
For this reason, people's borderline mysticism about "code-morphing" strikes me as strange, given that it remains a solution in search of a problem. It's just an implementation technique, folks. It's not even as fundamentally radical an implementation technique as it initially sounds; it's a slippery slope from microcode+trace cache to "code morphing." Does it build a faster CPU? Not nearly. Does it build a more power-conservant CPU? Just barely, and it's unclear the world cares as much as Transmeta want it to. So who gives a rat's ass? It sounds like a clever idea at first, but don't really clever ideas, like, accomplish stuff?
The problem is this, there are certain mathematical problems that are known to be Hard. Traveling Salesman, Knapsack, etc. There are no shortcuts to solving these problems. Many mathematical problems can be proven to be in this class of problems. Nobody has, to date, publicly, shown that factoring numbers is Hard, and nobody has shown that it isn't.
We stand on even sketchier ground than this. Travelling Salesman, Knapsack, and the "etc." referred to above are "NP-complete" problems-- they are the hardest problems in NP, the class of problems whose solutions only expand their inputs polynomially. (For an example of a problem outside of NP: given a number in base 2, represent it in base 1 (e.g., in tick marks. The output of this problem is O(2^n) for input of length n.)
Factoring is in NP; however, we don't know whether it is NP-complete.
How "hard" are these NP-complete problems? Nobody knows. Most "serious" folks hypothesize that polynomial-time solutions to these problems aren't possible on conventional computers (essentially, because lots of smart people have worked on it and haven't found one). However, nobody has proven this yet; and because of the equivalency of NP-complete problems, a solution to one can be transformed mechanically into solutions for all NP-complete problems.
So, to summarize: we don't know how hard the NP-complete problems are; and factoring can only be as hard as the NP-complete problems (and just might be easier). Treating NP-complete problems as "hard" is a reasonable working assumption, but it is just that.
The sad part is that x86 self-virtualization is so difficult in the first place. It would be much easier if user-mode accesses to control registers were disallowed. How hard could that be for Intel? Or for AMD?
Alas, you would have to change enough stuff that it wouldn't feel like the x86 anymore. The canonical example of the x86's unvirtualizability is the eflags register. This register is a jumble of supervisor state and user state; for example, condition flags set by arithmetic operations appear there, as does the flag that enables/disables external interrupts.
There's an instruction, POPF, that replaces the contents of the eflags register with the top of the stack. If user-level code mucks with supervisor flags, the hardware silently ignores these attempts, with no fault to give a would-be virtual machine monitor a hint that something fishy is happening. That's a problem for VMware; every time the linux kernel executes one of its restore_flags macros, it performs a POPF that attempts to alter the state of the interrupt flag. VMware needs to notice this somehow; currently, the hardware provides no help.
This POPF problem could be solved by creating some sort of processor mode, analogous to the virtual 8086 mode used by windows DOS boxes, that makes POPFs that attempt to modify the interrupt flag from user mode trap. However, there are other "unvirtualizable" attributes of the x86 that go a bit deeper.
And VMWare still has trouble; it can handle only specific OSes in guest machines. By contrast VM/370 (or whatever IBM is calling it these days) can handle virtually any guest OS.
There is some truth to this. Malicious x86 guest OS'es will probably always be able to tell that they are running inside a VM.
Still, it gets me down when people imply that VMware is some goofy hack that happens to work with Windows and Linux. By design, nothing prevents us from running more exotic OSes. The list of random OS'es that work in VMs is, in my biased opinon, pretty impressive: Plan9, BeOS, AtheOS, Solaris, OpenStep, QNX. Check out vmware.guest.misc for more.
(unlike VMWare, which I'm told runs at about half speed or less)
Ahem. Excuse me? I'd like to have a word with whoever told you this. Meanwhile, the 30-day eval is free; why not try it, rather than repeat some nasty limerick about VMware you read on the men's room wall?
Still, it runs, and only crashes occasionally due to some thrashing problems.
Why on earth would you put up with it crashing ever?
It might be the right track for your rah-rah Linux agenda, but it's probably the wrong track for Sun. What does Sun think it can do Intel servers running Linux that IBM, HP, et al. can't? With neither hardware nor software to differentiate these boxes, what will sell them? Ed Zander's good looks?
I'll go out on a limb here, and predict that this is the beginning of an SGI-esque downward spiral into total irrelevance. Any bets on when Sun rolls out a new logo?
The reason that Robert Loves's pre-empt patch has not gone in is because that it can cause subtle bugs.
Correction: it exposes subtle bugs. Conceptually, almost any bug possible with the preemption patch must exist on an SMP system as well; in both cases, arbitrary kernel instruction interleavings are possible unless explicitly synchronized against.
Perhaps there's a bit of confusion here. In the scientific computing/benchmarking world, "kernel" refers to an inner loop of a compute-intensive program that has been extracted for benchmarking purposes. There's no dishonesty here; they're just using a definition of the word you haven't encountered before.
No. Linus has allowed binary-only modules into the kernel provided they communicate with the kernel using well-defined APIs. For instance, the vmware package includes a binary-only kernel module.
Hmm, funny. What is this/usr/lib/vmware/modules/source directory doing on my system then?
Slashdot Mirror
Most North American sports fans I know assume cycling is just a test of physical fitness, comparable to competitive marathon or track and field. Not so. Drafting in cycling is crucial; at the speeds the pros race, sitting on another rider's wheel saves about 40% in power compared to riding into the wind. Team strategy and tactics more often determine winners than raw fitness.
It's funny that NASCAR and pro cycling occupy almost opposite public images in the North American gestalt: hirsute, homegrown, working class sport vs. effete, Euro, vaguely yuppie-ish sport. But the sports' underlying structures (strategy, tactics, etc.) are surjective.
Microsoft owns VMware as well, or at least has invested in it.
No. I don't know where you think you heard this, but it's completely false.
I just made those up, but do you see how annoying it is? The "X, Y, and Z" title format is naturally grandiose; it says to the reader, "Brace yourself! The following incredible story will arc from X, to Y, and then all the way over to Z!"
Perhaps if employed less sparingly, the "X, Y, and Z" title format could be effective, but this being slashdot, it rarely delivers on its promise. When I see a slashdot article in this format, I know that the actual story will be about some lawsuit which pertains directly to Z, but only tangentially relates to X or Y.
On the one hand ... VMWare supports specific OSes, not just any x86 OS. So one wonders how complete their virtualization is.
Wrongo. When we say "VMware supports FreeBSD," we mean that customers can call us and expect us to help with problems running FreeBSD in a VM. "Unsupported" guests that work fine include Plan9, BeOS, Openstep, FreeDOS, and AtheOS. VMware is not just a big dumb hack that happens to work for Linux and Windows.
Arrggh, it's too hard.
I work for VMware. if you want to believe we've corrupted Kevin's precious bodily fluids, feel free. I don't speak for the company, and I know nothing beyond what slashdot has posted about plex86. Consider yourself disclaimed.
If I understand the story correctly, plex86 has basically surrendered. They've given up on running arbitrary supervisor level code; the Linux guests that Kevin refers to above require a patch to "fix" something the new "lean, mean" plex86 gets wrong.
If Linus is feeling even vaguely himself, he will not accept this patch. Ordinarily, people trying to put stuff into the kernel that a) hurts performance, and b) fixes no real problem, but c) is critical to some contrived project that seems really important to the contributor get entertainingly flamed, and then shown the door. In fact, Kevin's most likely motivation for submitting this as a Slashdot story is to marshall support for his Linux patch.
Even if Linus does accept this patch, I can guarantee you that Microsoft, the FreeBSD team, the now non-existent Be, etc., won't all be taking helpful hints from Kevin about which x86 features they may and may not use. Ergo, there is nothing interesting (either commercially or geekily) you can do with plex86; the most it can hope for is to run recent-ish Linux guests on recent-ish Linux hosts. Bestill my heart.
On the upside, maybe Kevin will stop implying that VMware stole Bochs, now that he's spent four years trying to clone our software and has finally admitted defeat.
VMware doesn't need a device driver, if I'm not mistaken.
/dev/vmmon
Actually, we do. ls -l
The virtual machine monitor itself must run on the bare hardware, so we need help from the kernel.
Keith Adams (VMware engineer)
Why must a gender difference be evidence of overt or covert discrimination? In my opinion, the CS gender differential comes from differences in hardware, rather than software. Drop me in the "nature" bin on this question: I think that women, on average, differ from men in such a way that they are less likely to be interested in computer science. I could get into why I believe this, but it's all anecdotal, and wouldn't convince anybody who didn't already agree with me.
Note that this in no way justifies discrimination against women. This discrimination is still clearly a reality, and must ultimately be eradicated root and branch. It is wrong to prejudge individuals by the group they belong to, not, as extreme "nurturists" would hold, because there are no differences among groups, but because respect for ones fellow humans requires that we treat them as equals. I.e., equality of opportunity is a matter of ethics, and ethical principles shouldn't be held hostage to questions of animal biology.
For those who wish to wring their hands about this gender discrepancy, must every field be split, 50/50 (well, 51/49)? Is the only possible "just" society one where soldiers, professional athletes, nurses, artists, even rapists, thieves and murderers, are exactly as likely to be male as female? What if the average woman doesn't care very much about computers, or artillery, or how to hotwire cars, not because of Barbie, or because their math teacher didn't call on them in seventh grade, but because she simply finds other things more interesting? If such women exist, discrimination "on behalf" of women in many male-dominated fields would ultimately make women less happy. It would, by definition, divert women who would otherwise be happier doing something else into male-dominated careers, to satisfy some sort of mathematical imperative of justice.
That is why I'm very leary of those who would rush to affirmative action-ize CS. You might not side with me on the "nature" side of this question; but regardless, I think the nature/nurture debate in this case is too far from resolution to be sure whether such programs are a net benefit or harm to womankind.
Intel has a very strong history of designing chips that ramp up very well (except for their one CPU engineering failure, the Pentium Pro, which was too ambitiously designed).
While your overall thesis is correct, your parenthetical diss of the PPro is ass-backwards. The PPro core is the same core that has been tweaked into the PIII. It had an approximately seven-year productive span, during which it was very competitive, although it was considered a monstrosity in its original incarnation as the Pentium Pro. I.e., the PPro is exhibit A in your argument, not some sort of exception to be excused.
Miraculously, someone at Intel stowed the x86 crackpipe, preventing some sort of segmented/overlay nightmare like the one you describe.
Reading the paper, I get the impression that this is mostly typical undergraduate hand-wringing about the gulf between academia and industry. That's fine, as far as it goes, and I've certainly indulged in my fair share of it. However, as an occasional student of stuff other than computer science, I'm a bit worried by their choice of terminology.
To sum up: Post-freaking-modernism??? Do these people have any idea what a plague on the humanities the loose collection of intellectual conceits known as "postmodernism" has been?
I've tried my hand at reading Foucault/Derrida/Barthes/etc., and their secondary sources. It's exceptionally difficult, but not in the way that, say, a complex algorithm is difficult. It's difficult in the way religious texts, or David Lynch movies are difficult; i.e., the difficulty is a smokescreen to keep the reader from catching on that this is all a bunch of bullshit.
This sort of deal typically begins with, "I will argue that {truth,reason,science,gender} is {non-existent,socially constructed,a masculinist plot}." Several hundred extraordinarily poorly written pages follow in which the author, in varying degrees of good faith, actually tries to argue these points. Of course, if truth is socially constructed, we all have no basis upon which to discuss anything. Rather than calling one another on it, the postmodernists collectively wink at one another, and promise to take one another seriously, and quote one another every chance they get. It's academics by pyramid scheme.
I understand why humanities people, even bright ones, fall for this routine, since they might go through all of their undergraduate and graduate education without encountering a single academic who hasn't drunk from postmodernism's poisoned cup; but why on earth would computer scientists be visiting this curse on a journal I subscribe to?
To those posters above tempted to give in to the siren song of self-referentiality, who might be thinking, "Hey, some of my CS classes are boring, maybe we need some of this radical 'postmodern' stuff to kick boring old CS in the pants," remember: computer science is very, very young. New ideas and techniques are thick on the ground in fields as diverse as graphics, systems, theory, AI, and software engineering. Literary critics eventually turned to postmodernism in part because it seemed like there was nothing left to say, and this postmodernism stuff, bullshit or not, was at least different. In computer science, we are still learning how to write a well-structured novel.
VMware is a bit of a special case, because it's inordinately difficult to clone. Had the plex86 project been successful, very few individual Linux users would be buying VMware Workstation. Even still, for months in 1999 the top few google hits on "vmware" were sites with pirated serial numbers.
(Disclaimer: I work for VMware.)
(On most Linux boxes, stacks grow towards lower addresses, except on Alpha, IIRC. Heaps depend on the libc implementation, not the CPU.)
Nope. At the time I was doing the i960 port of ucLinux, I had to teach Linux to handle stacks growing towards higher addresses. The kernel stack overflow checking code would unconditionally look at the low end of the kernel stack; on i960, it was necessary to look at the high end. This was in 1998, eons after the alpha port had been integrated. Since then, the pa-risc port has also had to cope with "backwards" stacks, and it wouldn't surprise me if some of the goofball architectures (like SuperH) had strange stacks too.
Note that having stacks grow towards higher addresses doesn't cure buffer overflows. It sounds promising; how will you overflow a string to write over a return address if the return address is at a lower virtual address than the string? But architectures like i960 and pa-risc are still vulnerable, because sometimes stack buffers are passed to called functions. If you can coerce the called function into overflowing its caller's buffer, you can overwrite the called function's activation record. It's a bit trickier, but still possible.
SMT has been quietly enabled for Xeon P4's for some time. If your BIOS is capable of preparing an MP spec for the SMT P4's, you can run commodity OS'es with "virtual" processor counts higher than your physical processor count today.
Second of all, intel stretched their pipeline to 40+ stages, this means that the penalty for pipeline stall, branch perdiction miss, context switch, etc is *HUGE*. AMD's Athlon pipeline was a lean 7 stages.
Nicely confabulated! When making stuff up to prove a point, you might as well go for the jugular. The pipeline lengths in question are 20 and 10, not 40 and 7. Incidentally, a long pipeline has nearly nothing to do with "context switch", at least as that term is commonly used (i.e., switching from one process context to another). Any pipeline issues caused by a context switch are dwarfed a thousand times over by cache and TLB issues.
Aside: what is with the short pipeline fetishism on the part of AMD partisans? You guys realize that they had four- and fiv-stage implementations of MIPS CPUs back in the early '80's, right? Imagine how brilliantly fast a MIPS r2000 would be in 3.0GHz! Oh, wait, you can't make an r2000 run at that clock speed. Hmm. Maybe pipeline length is just one parameter in a complicated design space, and we should look on manufacturer variations as differing technical solutions. After all, that's how we treat cache design, functional unit choices, and myriad other microarchitectural parameters.
No, that sounds complicated. It must be an Intel conspiracy to corrupt our precious bodily fluids...
Why did Intel do this? They were scared because AMD beat them at their own game.
Then in a few sentences, you say:
You'll notice now that Intels best P4 is faster then AMD's best part right now...
Umm, so how was Intel "beaten at its own game"? A bit of history, for perspective.
The Pentium III is the same core that was originally sold as the Pentium Pro. That core was introduced in 1995, and Intel is still squeezing performance out of it. At the beginning of the PPro's lifetime, it was an extremely ambitious design for the physical processes then available; people called it a too-hot, too-big, too-transistor-intensive monstrosity that would never be practical. Towards the middle of its life, in the years '97 to 2000 or so, the PIII was nicely matched to the physical parameters of then-current fab technology, and Intel produced modest shrinks and speed bumps seemingly at will. Those were the salad years of the PIII. Now physical technology has moved further down the road, and the PPro core is showing its age. It's leaving performance on the table that could be scooped up with transistor-intensive techniques like trace caches, more functional units, issue width, etc.
Like almost every other design generation of every CPU, ever, the P4 has a more complicated pipeline than its predecssors. Just as in 1995, the first year showed pretty "meh" performance, with much armchair punditry claiming that it's a monstrosity. Now, about 18 months after its introduction, the P4 is scaling well. AMD, on the other hand, is struggling to wring a few more modest speed bumps out of the K7 before it limps along to the end of its design life. The AMD partisans hold out hope for the K8, generally forgetting that the K8 is a K7 with a 64-bit bag on the side.
It saddens me to type this on my Athlon, but there's a strong likelihood that AMD's years in the sun are over. Five years hence, we might be looking back at the years 1999-2001 as a lost golden age of competition in the x86 CPU space.
To remedy the situation, processors ratings need to be measured in IPC*MHZ [instructions per cycle] for both integer and floating point operations. Then it would be pretty clear to consumers what was going on.
Any simple attempt at measuring performance will end up being simplistic. The big problem with your proposal can be summed up as: which instructions? NOPs? SIMD floating point? The instructions that make up Quake III, or gcc, or my LISP stock market prediction application? What about when the instruction sets of the CPUs differ, ala SSE2? Performance characterization really is difficult; anybody who claims otherwise is trying to sell you something.
ofcourse. that however, is a clever hack. not a fix.
Umm, safe mode is the documented, standard way of fixing fatal driver problems with windows. There's nothing "clever" or "hacky" about it. You claimed windows refused to boot in VGA mode, and grandparent pointed out that this was because you are ignorant. Thank the man and move along.
Christ, I get a troll mod, *and* get called stupid.
In fairness, you could only be one or the other. I know where my money is.
This whole "code-morphing is for power saving" line is a rather transparent rewriting of history on the part of Transmeta. At the time of Transmeta's founding, they clearly hoped that transparent, online software optimization would be so effective that they'd produce a much faster x86 than is otherwise possible. When it became clear that they'd underestimated x86 performance curves, they needed some reason for having spent all that money on Linus's salary. An almost random implementation side effect happened to consume less power than other x86 CPUs; so, the fiction that the world was clamoring for fractionally lower-power x86 cpus than are available from its competitors was invented.
I don't have any sort of privileged information about this; it just seems to fit the data well. How would a company whose business model is Transmeta's current one ever get founded, given that it involves two leaps of faith: first, that people want to buy low-power x86'es, and second, that this "code-morphing" jiggery-pokey will actually produce a low-power x86. It would be much easier to get started on the assumption that these things would actually be fast (which they clearly hoped), since there's a proven market for fast CPUs.
For this reason, people's borderline mysticism about "code-morphing" strikes me as strange, given that it remains a solution in search of a problem. It's just an implementation technique, folks. It's not even as fundamentally radical an implementation technique as it initially sounds; it's a slippery slope from microcode+trace cache to "code morphing." Does it build a faster CPU? Not nearly. Does it build a more power-conservant CPU? Just barely, and it's unclear the world cares as much as Transmeta want it to. So who gives a rat's ass? It sounds like a clever idea at first, but don't really clever ideas, like, accomplish stuff?
What language do you think your C compiler is written in?
The problem is this, there are certain mathematical problems that are known to be Hard. Traveling Salesman, Knapsack, etc. There are no shortcuts to solving these problems. Many mathematical problems can be proven to be in this class of problems. Nobody has, to date, publicly, shown that factoring numbers is Hard, and nobody has shown that it isn't.
We stand on even sketchier ground than this. Travelling Salesman, Knapsack, and the "etc." referred to above are "NP-complete" problems-- they are the hardest problems in NP, the class of problems whose solutions only expand their inputs polynomially. (For an example of a problem outside of NP: given a number in base 2, represent it in base 1 (e.g., in tick marks. The output of this problem is O(2^n) for input of length n.)
Factoring is in NP; however, we don't know whether it is NP-complete.
How "hard" are these NP-complete problems? Nobody knows. Most "serious" folks hypothesize that polynomial-time solutions to these problems aren't possible on conventional computers (essentially, because lots of smart people have worked on it and haven't found one). However, nobody has proven this yet; and because of the equivalency of NP-complete problems, a solution to one can be transformed mechanically into solutions for all NP-complete problems.
So, to summarize: we don't know how hard the NP-complete problems are; and factoring can only be as hard as the NP-complete problems (and just might be easier). Treating NP-complete problems as "hard" is a reasonable working assumption, but it is just that.
The sad part is that x86 self-virtualization is so difficult in the first place. It would be much easier if user-mode accesses to control registers were disallowed. How hard could that be for Intel? Or for AMD?
Alas, you would have to change enough stuff that it wouldn't feel like the x86 anymore. The canonical example of the x86's unvirtualizability is the eflags register. This register is a jumble of supervisor state and user state; for example, condition flags set by arithmetic operations appear there, as does the flag that enables/disables external interrupts.
There's an instruction, POPF, that replaces the contents of the eflags register with the top of the stack. If user-level code mucks with supervisor flags, the hardware silently ignores these attempts, with no fault to give a would-be virtual machine monitor a hint that something fishy is happening. That's a problem for VMware; every time the linux kernel executes one of its restore_flags macros, it performs a POPF that attempts to alter the state of the interrupt flag. VMware needs to notice this somehow; currently, the hardware provides no help.
This POPF problem could be solved by creating some sort of processor mode, analogous to the virtual 8086 mode used by windows DOS boxes, that makes POPFs that attempt to modify the interrupt flag from user mode trap. However, there are other "unvirtualizable" attributes of the x86 that go a bit deeper.
And VMWare still has trouble; it can handle only specific OSes in guest machines. By contrast VM/370 (or whatever IBM is calling it these days) can handle virtually any guest OS.
There is some truth to this. Malicious x86 guest OS'es will probably always be able to tell that they are running inside a VM.
Still, it gets me down when people imply that VMware is some goofy hack that happens to work with Windows and Linux. By design, nothing prevents us from running more exotic OSes. The list of random OS'es that work in VMs is, in my biased opinon, pretty impressive: Plan9, BeOS, AtheOS, Solaris, OpenStep, QNX. Check out vmware.guest.misc for more.
Keith Adams (partisan VMware mts)
(unlike VMWare, which I'm told runs at about half speed or less)
Ahem. Excuse me? I'd like to have a word with whoever told you this. Meanwhile, the 30-day eval is free; why not try it, rather than repeat some nasty limerick about VMware you read on the men's room wall?
Still, it runs, and only crashes occasionally due to some thrashing problems.
Why on earth would you put up with it crashing ever?
Keith Adams (openly partisan VMware mts)
It might be the right track for your rah-rah Linux agenda, but it's probably the wrong track for Sun. What does Sun think it can do Intel servers running Linux that IBM, HP, et al. can't? With neither hardware nor software to differentiate these boxes, what will sell them? Ed Zander's good looks?
I'll go out on a limb here, and predict that this is the beginning of an SGI-esque downward spiral into total irrelevance. Any bets on when Sun rolls out a new logo?
The reason that Robert Loves's pre-empt patch has not gone in is because that it can cause subtle bugs.
Correction: it exposes subtle bugs. Conceptually, almost any bug possible with the preemption patch must exist on an SMP system as well; in both cases, arbitrary kernel instruction interleavings are possible unless explicitly synchronized against.
Perhaps there's a bit of confusion here. In the scientific computing/benchmarking world, "kernel" refers to an inner loop of a compute-intensive program that has been extracted for benchmarking purposes. There's no dishonesty here; they're just using a definition of the word you haven't encountered before.
No. Linus has allowed binary-only modules into the kernel provided they communicate with the kernel using well-defined APIs. For instance, the vmware package includes a binary-only kernel module.
/usr/lib/vmware/modules/source directory doing on my system then?
Hmm, funny. What is this
Keith Adams
(VMware engineer)