Here's my theory: an excessively hot troposphere is causing global warming, i.e. waste heat generated by human activity. My off-the-cuff theory states that the energy leakage from our houses, the altered radation patterns of our roads and asphault cities and farms, the volumes of hot waste gasses we continuously dissipate into the atmosphere, are causing the increase in temperature, and that CO2 levels are a side effect of the increased energy output. Drop CO2 emissions to zero, and temperature doesn't change a bit. But I'm not a climatologist.
I would happy advocate lowering CO2 emissions - if someone - anyone! - showed causation. Your (b) is coincidence (literally: the two occur at the same time, co - indicent), not causation. Your (c) is the result, not causation.
I want to see an experiment that shows - in a closed system - that CO2 levels explain 100% of global warming AND that reducing CO2 levels cause temperature to react immediately; I want to see someone explain that CO2 is the one and only cause. No one can, because no one has anything better than a guess based on correlation.
I do not want to see another computer simulation that works like: "Assume CO2 causes global warming. Fit a curve to the last 40 years of data. See if the curve fits for another ten years". That proves nothing, and explains nothing; it merely demonstrates that the outputs follow a trend, and proves only correlation.
I left Inconvenient Truth disappointed, actually. Oh, the movie convinced me that global warming is coming, is quite inevitable, and the next 50 years will be deadlier (think hurricanes, tsunamis, drought and cold snaps) than the world has seen in a long time.
But I didn't leave with a single idea of WHAT TO DO ABOUT IT. Al Gore keeps pointing to CO2 levels as The Thing We Must Fix; I was totally unconvinced. He proved correlation, not causation. He spent much of the movie talking about the mechanisms the environment uses to self-regulate, but nothing he suggested be done involves those mechanisms. He talked about how the greenhouse effect works in theory, but pointed to no experimental evidence suggesting that CO2 is the cause of global warming. For a talk/movie as well-reasoned as Al Gore's, this lack of connection is deeply disturbing.
Hint to climatologists: when a physicist wants to prove a correlation between, say, gravity and the curvature of light, he comes up with a theory and a model, then designs an experiment (usually involving inputs outside what has been observed before) where he should be able to predict the outcome, and tests whether the experimental results matches the model. Climatologists aren't experimenting. Right now, climatology research is about fitting a model to the data: useful for predicting the future, but too incomplete to predict how an input will affect the system - too incomplete to use as a tool against global warming. (And I apologize to any climatologists in the crowd. Bluntly, you can do better, and part of the blame is the rest of us damn fools who aren't giving you enough resources to do good research.)
My concern about global warming is not that we would fail to react. It is that we would react the wrong way. That we would confidently reduce CO2 emissions, only to discover in 50 years that it had little to do with CO2. That we would block out solar radiation and cool the Earth at the same time the planet dumps heat - and inadvertantly push ourselves into a worse ice age. That we would succeed in keep the temperature constant, then watch Earth's ecology shatter because we missed an important heat wave.
What I _want_ to see is a hell of a lot of climatology research. (1) from Big Oil, who need to get it into their collective heads the difference between cover-your-ass research that absolves Big Oil from blame and productive research that can portray Big Oil as an environmental champion (hint: cover-your-ass research looks for flaws in CO2 models and sampling techniques without suggesting any new ideas. Productive research would explain how X gives a more accurate model than CO2 emissions). It will probably hurt short-term profits. But the company who wants to be dominant in 50 years had best get started. (2) from the government, which can throw enough money at the problem to give it the credibility it currently lacks.
I'm not here to be an apologist. But seeing activists run off to save the world - when they can't even tell me whether their contribution will help or hurt - does not inspire confidence.
One possibility is that the rootkit directly passes through all hardware - that's the "native" case (and actually required... changing out the underlying hardware model while an OS is running is just short of impossible).
Except... she's wrong. Once you pass through underlying hardware, you regain the ability to detect the rootkit. How?
For each page of memory: DMA the page into a buffer Compare that page against what reads to that page see
If you ever find a difference, you're either in a hypervisor, or you're at 0xa000 and playing with the SMM memory under the VGA adapter:-)
This problem is why all the modern virtualization solutions dare not pass through arbitrary hardware. It's a gross security violation because it allows the OS to subvert the hypervisor (just change the DMA read to a write). Want to be smart and virtualize DMA? That means virtualizing DMA on every PCI card (even unknown ones), plus DMA-analogues like the GART. VT-d could do it, but there are no working prototypes of that yet.
In short, a Blue Pill that performs as advertised is impossible.
I went onto Facebook this morning, read the open note, started to be happier... then hit the privacy page, and was horrified.
Facebook has done exactly what Microsoft tries to do. They take a list ("don't tell people when my relationship status changes", "don't tell people when I leave a group", "don't tell people when I change an interest") and fix that list. Remind anyone of how Microsoft complied with an antitrust ruling about bundling IE and "fixed" it by shipping a tool that lets you change your default browser preference?
Facebook COMPLETELY MISSED THE POINT. They fixed every gripe, but totally failed to understand my privacy concern. I don't want to read minutae about everyone else's life every time I log in; I don't want people to be reading minutae about my life (including every typo I correct) on their front page. And I would really like to NOT know that somebody I wrote a message to has rewritten most of their page but ignored my message.
Privacy is a two-way street.
Privacy is the world not knowing every minutae of my life.
Privacy is me not knowing the details of everyone else's life.
The original (US Supreme Court) right to privacy was about not getting birth control junk mail - it was about not having to read some interest group's anti-abortion snail-mail spam.
Privacy is not a laundry list of checkboxes. Privacy is not a band-aid to be applied after you totally fuck it up.
The "copyright infringement isn't piracy" argument is the modern equivalent of the Nazi argument - once you use it, you've already lost. Large-scale copyright violation IS piracy: you are hijacking the owner's right to distribute in favor of your own whims, which is very close to "piracy" and a long way from "infringement".
The No Electronic Theft Act has no provision permitting downloading. It carves out a small exemption - small-scale infringement for non-financial gains appears to not be a CRIMINAL act - but the law you cite says nothing about civil liability. (IANAL, but I apparently read the law more closely than you).
"We know what happened" - yes, we do. Destruction of evidence implies guilt. The AC who believes otherwise and is stupid enough to try that hearsay stunt in court can enjoy a nice vacation in prison - and I'll be glad for it.
Nested page tables isn't in the current generation of AMD chips (and thus, they will do no better than Intel's VT). I am VERY eagerly awaiting the next generation of chips.
Pacifica has a slight advantage in that it supports ASIDs (Address Space IDs, see your OS textbook's section on page tables), a long-overdue x86 feature. But even theoretically, that's not going to make up the difference.
Incorrect. Read the specs, and you'll see that VT's original spec makes no mention of shadow page tables and SVM lists it as an implementation-dependent feature. BTW, implementation of nested page tables (AMD's version) was slated for RevF, but slipped and last I saw (from The Register) was slated for RevH. It's on Intel's road map, I don't know how far out.
Because there's a physical component to the release process. They can't press the CDs/DVDs fast enough to beat the copy stolen from the pressing plant onto the internet.
Maybe if they didn't contract out CD/DVD burning to the lowest bidder - if they'd spend a few more dollers getting the physical media from a company that takes security seriously - they wouldn't get stolen in pre-production?
Seriously. I see whining about how pirates beat the real thing to market? That shouldn't happen - and it's the manufacturer's own fault if it does. (Yes, the pirates are doing something illegal, it would be nice if law enforcement got them... but any sane manufacturer knows that a certain amount of illegal skimming of the business will occur which law enforcement cannot clean up in a timely manner, and factors the waste in as cost of doing business). The faster to-market time is a problem that can be (easily!) solved with money - because the piracy market is clearly costing them more than the extra security would. Of course, instead of fixing the problem, we now get to be audience to the time-honored game of Blame Someone Else.
Re:without HyperTransport, AMD would be dead
on
IBM Opts for AMD
·
· Score: 1
Intel's offering: 2xWoodcrest, 169K throughput, $2.93/unit cost, 64-bit OS, 3.0GHz CPU listed at $1350, available Nov22 2006.
AMD offering with comparable RAM size: 2xOpteron 280, 114K thoughput, $2.99/unit cost, 32-bit OS, available May5 2006.
I looked for, but did not find, any 64-bit OS vs 64-bit OS comparisons (they only have 64-bit on 4-way Opteron, which isn't fair), this is unfortunate as the larger address space should make a real difference in TPC benchmarks. Also, the AMD ones are on 280s, AMD has 285s with larger caches now.
Difference in raw score is impressive though. It's a race... can DDR2 + RevF improve Opteron enough in the six months before "availability" of Woodcrest?
Note that TPC numbers are usually price/performance; already, AMD is in a dead heat (if not ahead) here, and then factor in the six month release date difference. Hmm... looking at the numbers, the best 2xdual-core Xeon system reached $3.28/unit cost, Woodcrest made it to $2.99/unit, AMD 2xdual cores reach $2.73 (on a 128GB mem config) and 4xdual reached $2.13. Well... Intel is finally in the right ballpark for cost/performance! Now if only they had a pre-production 4xdual to show off?
Thanks for the link. Most interesting.
Re:without HyperTransport, AMD would be dead
on
IBM Opts for AMD
·
· Score: 3, Insightful
Crap benchmarks. Seriously, those reek to high heaven.
Comparing FB-DIMM to DDR. FB-DIMM has something like 4x the bandwidth, and isn't even available outside Intel OEM samples. AMD is moving to DDR2 real soon. Comparing pre-production Intel parts to half-year-old AMD parts isn't benchmarking. It's PR.
The benchmark list is mostly home-brewed. A hacked-together transaction processor (when there are industry standard ones out there for comparison - TPC numbers would be ideal), and RSA crypto optimized for the Intel processor.
Their SAMP benchmark and portgresSQL benchmark are worthless (they dropped to single-socket for them). The only common ones on the list are specInt and specFP - both single-processor benchmarks that don't show scalability.
The second link is a well-known example of Anand running a benchmark and discovering severe performance problems (i.e. mysql scales very poorly with more Opteron processors due to a mysql bug) - then still proclaiming Intel's huge victory.
Woodcrest is faster in single processor configurations. Duh - it's a preproduction model compared to AMD's 3-year-old design. These benchmarks ultimately say NOTHING about multiprocessor configurations - I have yet to see any useful 2-socket benchmarks.
See, this is why I still read Slashdot. Informed opinions from interesting people! Thanks for stopping by to chat.
Please try to separate XenSource from the Xen community. Many of us don't work for XenSource and many of us think that XenSource does stupid things (this being a good example).
Fair - and in hindsight, I should have noted that distinction, apologies. (That particular MS/XenSource alliance happens to be at the top of my stupid list... it hurts Xen, XenSource, all other virtualization businesses (via FUD), and ultimately helps only Microsoft).
I actually don't like VMI either. I still believe the hypervisor should be hidden - if the OS wants a virtualized timer, it should use a paravirtualized device driver, the API for which is independent of the hypervisor's core interface - but I don't think that loading a ROM is the way to load an interface. It's re-inventing BIOS. Frankly, I don't think there is a good solution. And once the CPU vendors get their acts together and actually virtualize the MMU (yup, they virtualized the CPU but not the onboard MMU, VT/Pacifica v1 is as weak as a 286) then the pressure on paravirtualization decreases as the performance advantage disappears. (Device paravirtualization is still needed - but that's easy! And the ground is ripe for competition in the feature set of an emulated device.)
VMware went to OLS and presented a paper demonstrating a VMI interface that runs either Xen or VMware at the same speed as the Xen interface. Xen has never tried to run on a VMware hypervisor, but XenSource went and signed a deal to run on the (future) Windows hypervisor. My opinion is that Xen is a bunch of hypocrites: they complain about how VMware isn't open, then go sign a deal with the least open company of all. Of course, I'm biased.
Xen wants VMware to adopt the Xen hypervisor interface. This is impossible. The Xen interface is too tightly coupled to the Xen hypervisor; it's missing pieces that are necessary to run the VMware hypervisor at reasonable performance. VMware doesn't really care which interface actually proliferates (as in, there will be a layer of interface glue regardless), so long as the interface is good enough. Xen's interface is not good enough. As of two weeks ago, Xen and VMI were the only two interfaces out there.
Greg K-H's gripe with VMware is that the kernel module isn't open source. Yes and no (I don't want to argue - the code is open but not GPLed), the point is that he's spending more time complaining about Xen and VMware than it would take to actually mediate the problem. (Which, thankfully, someone else is doing instead, with paravirt_ops).
Finally: I saw more pot-shots about being unable to benchmark VMware in the original article. That changed several months ago, benchmarks are now allowed by EULA. Certain companies ought to stop spreading FUD...
The stability of a driver is a function of how many useful bug reports get into the hands of the developer who wrote the driver. Linux survives because Linux has far more developers - any kernel hacker can fix a problem, but almost no end-user problems ever get fixed (hence, mom and pop hate Linux because their grips don't get fixed, nor even heard). On Windows, there are fewer developers, but Microsoft (despite their faults) has done much better about getting error reports to the people who can fix the bugs. My employer makes great use of the Windows error reporting tools.
The Linux community does a good job of getting reasonably clean code into Linux. But in the process, they have adopted a horrific Not Invented Here complex - getting new code into Linux is a multi-month process at best (and multi-year if there's not a core kernel hacker championing the code). Windows is sufficiently modular that it's just a matter of loading a new driver - sometimes the new driver is good and sometimes it's crap. But Microsoft doesn't demand that developers run only officially blessed sources (module non-GPL tainting), receive two tons of junk mail, and get flamed by seven people with three mutually contradictory gripes, two of whom are flaming only for political Code Wants To Be Free(tm) reasons.
Windows drivers got much better when they started getting more user-generated bug reports by providing automated tools to collect such reports. (Admittedly, an approach started by Mozilla.) Open source code has nothing to do with it. And the Linux community would do well to learn from that example.
*blink*. VMware could run Windows when it first started shipping products eight years ago. It's Xen that has only been able to run Windows in the past few months, with VT chips. And Xen has conspicuously NOT published any benchmarks of that configuration - which leads me to believe performance sucks. Are you talking about paravirtualization? Fun fact: after VMware released their VMI patches to LKML, the very next release of Xen patches included several interfaces cloned directly from the VMware interface.
Yup, that's what it takes. But when you think about it, WoW64 (running 32-bit apps on Windowx x64) or running 32-bit apps on Linux do the same thing, and take the mode switch on every system call. It's not all that expensive... a few thousand cycles... and world switches are less common than context switches.
*sigh*. I am deeply embarrassed to admit I missed where AMD's FX series moved to dual-core.
That said, memory benchmarks are more indicative of general workloads (not games). And, more importantly to me, memory benchmarks (and I/O benchmarks, which won't vary AMD/Intel) correlate strongly with perceived latency. I've always found a responsive, high-throughput system more important than straight-line game performance - though many prefer games.
Re: price/performance, AMD is dropping their price WHEN Intel chips come out... let's talk about price then.
Re: FB-DIMM, they have the same problem as Rambus: latency. The only way to counter latency is large cache.
I have yet to see a (credible) review of Woodcrest in a 2-socket configuration. (In three pages of Google results only the Anand comparison uses dual Woodcrest, and they show a 2P Opteron as slower than a 1P Opteron, yeah right). Woodcrest is faster, clocked higher... so it beats AMD's weakest point (a several-year-old cpu architecture), by a considerable margin. No one has thrown Woodcrest against AMD's strong point.
Yes, Woodcrest gets more bandwidth with Bensley architecture... you see the part about FB-DIMMs? I sense another RDRAM fiasco here... Intel isn't going to have a good multiprocessor bus for a long while yet.
But the point is about Core 2 Duo. And the benchmarks insist on comparing against "AMD's greatest" (single core) - how about an X2 5000? Nope, I can't find such a review (after reading 10 FX-62 reviews). And - bluntly - I'm going to ignore any review that doesn't compare BOTH an FX-62 AND a X2-5000 against a Core 2 Duo. Why? Because it's blindingly obvious that the fastest AMD chip could be either of those two depending on the benchmark... 2.8GHz vs dual 2.6GHz... yet reviewers don't even try. It's lousy benchmarking.
Alright, I've read four or so of the reviews listed in the comments here. My conclusions?
Core 2 Duo is faster than AMD for raw CPU. (Yes, this from a die-hard AMD fan)
Power-consumption, the brands are (finally) about at parity.
AMD's single processor-based advantage is memory: main memory access is still faster via on-chip memory controller. Admittedly, not worth much. BUT...
Criticisms.
I STILL have yet to see apples-to-apples comparisons. I'm pleased that these benchmarks are finally pitting DDR2 memory against DDR2 memory, but then they go and run a single-core AMD chip against a dual-core Intel chip. AMD single-core is a tiny bit faster per core than an AMD dual core, but single vs. dual makes a difference. Lousy benchmark design, folks.
All the AMD benchmarks I saw were on nforce4 MBs... AMD chips are up to nforce5 now (I've had one for the past two months). Yet the Intel MBs are using nforce5-generation chipsets. Again, lousy benchmarking!
No analysis of the source of differences. Architecturally, Intel has 4-way issue vs. AMD's 3-way issue and Intel has 4MB L2 vs. AMD's 1MB L2. Now, AMD moves to a 65nm process later this year and their caches are going to come up to size (Intel has always had larger caches); I expect AMD's next core to bump issue width up to 4-way later this year or early next year. So we really don't know if Intel's architecture is any better or not - we really have to wait until AMD matches these easier-to-adjust features, which I expect to take ~6 months.
I'm still a fan of AMD, and I'm still going to buy AMD. Why? These benchmarks didn't show it, but scale up the number of processors to 2 sockets (for a total of 4 cores) and AMD is going to kick Intel all over the map. In short, AMD's system architecture is still more advanced than Intel's, and that means more *to me* than the processor's actual speed.
The security risk is FUD by someone who doesn't understand virtualization, hypervisors, or modern OS design.
Virtualization demands that you be able to run arbitrary code at the most highly privilaged level. (for the pedants, QEMU is an emulator and does not do this; KQEMU is a virtualizer and does have this access). VMware uses the same mechanism - look at the device drivers it installs (the source code is shipped on Linux) and you'll find very similar code. That said, any device driver you install can provide the same access; do you trust Acme Inc who made your network card or video card?
The only security risk is if someone was able to overwrite the binaries on disk that get loaded via this mechanism. I assume they get installed chown-root to protect against this, but I have never actually run Parallels to know.
Is widely known to be hardly faster and significantly less mature/stable
Funny that I've been watching AM2 carefully for the past month, and only agree on "less mature". AM2 is not faster by itself, but it does open the door to DDR2 memory. Which means Intel went out of their way to compare an AMD on DDR memory with an Intel chip on DDR2, when Intel could very easily have set up the "equivalent" AMD system on DDR2. When they deliberately don't match memory technologies, I'm suddenly very suspicious of Intel's benchmark.
My socket-AM2 system has been stable - except for Tomb Raider, which does seem buggy (and I'm blaming graphics drivers for that). nForce4 is a buggy chipset period, I don't see how that is any advantage at all.
I expect Intel to jump ahead with their Core design, and then AMD to make up much of the difference with K8L later this year. But on the server side, AMD is going to eat Intel's lunch for a long while yet.
You can do the same thing that happens when that licensee or critical piece of code from a proprietary vendor gets sued out of existence. These problems are not unique to the Free Software world.
And while I'm at it... take a second to reread your post. It's FUD, pure and simple. We're used to FUD that says 'proprietary is safer', now we're starting to see FUD that says 'OSS may die, give us your support'. I happen to like OSS, make use of OSS in my everyday life, but being pulled into politics because of FUD does not appeal to me. And I realize you aren't trying to pull me in, but you are using the same rhetoric as people who are.
AMD's x86-64 does have segment limits (RevD and later), at the request of VMware. Also, AMD's Pacifica introduces ASIDs (Address Space IDs) into the TLB (RevF and later). It's x86, finally learning from all the other processors out there...
If you never intend to use the code, the GPL is fine. But if you ever intend to make money off of your own, similar code (arguably, a "derived work" once you've seen the GPLed code), the GPL basically prohibits you from looking at GPLed code.
So yes, the GPL is a license agreement. It basically says, "by looking at this code, you agree that any work you do in this area will be GPLed". You apparently either aren't in the same market as GPLed software, or don't mind GPLing your work; I happen to feel it's a restriction on my freedom, so I go out of my way to avoid touching GPLed code.
Slashdot Mirror
I would happy advocate lowering CO2 emissions - if someone - anyone! - showed causation. Your (b) is coincidence (literally: the two occur at the same time, co - indicent), not causation. Your (c) is the result, not causation.
I want to see an experiment that shows - in a closed system - that CO2 levels explain 100% of global warming AND that reducing CO2 levels cause temperature to react immediately; I want to see someone explain that CO2 is the one and only cause. No one can, because no one has anything better than a guess based on correlation.
I do not want to see another computer simulation that works like: "Assume CO2 causes global warming. Fit a curve to the last 40 years of data. See if the curve fits for another ten years". That proves nothing, and explains nothing; it merely demonstrates that the outputs follow a trend, and proves only correlation.
I left Inconvenient Truth disappointed, actually. Oh, the movie convinced me that global warming is coming, is quite inevitable, and the next 50 years will be deadlier (think hurricanes, tsunamis, drought and cold snaps) than the world has seen in a long time.
But I didn't leave with a single idea of WHAT TO DO ABOUT IT. Al Gore keeps pointing to CO2 levels as The Thing We Must Fix; I was totally unconvinced. He proved correlation, not causation. He spent much of the movie talking about the mechanisms the environment uses to self-regulate, but nothing he suggested be done involves those mechanisms. He talked about how the greenhouse effect works in theory, but pointed to no experimental evidence suggesting that CO2 is the cause of global warming. For a talk/movie as well-reasoned as Al Gore's, this lack of connection is deeply disturbing.
Hint to climatologists: when a physicist wants to prove a correlation between, say, gravity and the curvature of light, he comes up with a theory and a model, then designs an experiment (usually involving inputs outside what has been observed before) where he should be able to predict the outcome, and tests whether the experimental results matches the model. Climatologists aren't experimenting. Right now, climatology research is about fitting a model to the data: useful for predicting the future, but too incomplete to predict how an input will affect the system - too incomplete to use as a tool against global warming. (And I apologize to any climatologists in the crowd. Bluntly, you can do better, and part of the blame is the rest of us damn fools who aren't giving you enough resources to do good research.)
My concern about global warming is not that we would fail to react. It is that we would react the wrong way. That we would confidently reduce CO2 emissions, only to discover in 50 years that it had little to do with CO2. That we would block out solar radiation and cool the Earth at the same time the planet dumps heat - and inadvertantly push ourselves into a worse ice age. That we would succeed in keep the temperature constant, then watch Earth's ecology shatter because we missed an important heat wave.
What I _want_ to see is a hell of a lot of climatology research. (1) from Big Oil, who need to get it into their collective heads the difference between cover-your-ass research that absolves Big Oil from blame and productive research that can portray Big Oil as an environmental champion (hint: cover-your-ass research looks for flaws in CO2 models and sampling techniques without suggesting any new ideas. Productive research would explain how X gives a more accurate model than CO2 emissions). It will probably hurt short-term profits. But the company who wants to be dominant in 50 years had best get started. (2) from the government, which can throw enough money at the problem to give it the credibility it currently lacks.
I'm not here to be an apologist. But seeing activists run off to save the world - when they can't even tell me whether their contribution will help or hurt - does not inspire confidence.
Except ... she's wrong. Once you pass through underlying hardware, you regain the ability to detect the rootkit. How?
If you ever find a difference, you're either in a hypervisor, or you're at 0xa000 and playing with the SMM memory under the VGA adapterThis problem is why all the modern virtualization solutions dare not pass through arbitrary hardware. It's a gross security violation because it allows the OS to subvert the hypervisor (just change the DMA read to a write). Want to be smart and virtualize DMA? That means virtualizing DMA on every PCI card (even unknown ones), plus DMA-analogues like the GART. VT-d could do it, but there are no working prototypes of that yet.
In short, a Blue Pill that performs as advertised is impossible.
Facebook has done exactly what Microsoft tries to do. They take a list ("don't tell people when my relationship status changes", "don't tell people when I leave a group", "don't tell people when I change an interest") and fix that list. Remind anyone of how Microsoft complied with an antitrust ruling about bundling IE and "fixed" it by shipping a tool that lets you change your default browser preference?
Facebook COMPLETELY MISSED THE POINT. They fixed every gripe, but totally failed to understand my privacy concern. I don't want to read minutae about everyone else's life every time I log in; I don't want people to be reading minutae about my life (including every typo I correct) on their front page. And I would really like to NOT know that somebody I wrote a message to has rewritten most of their page but ignored my message.
Privacy is a two-way street.
- Privacy is the world not knowing every minutae of my life.
- Privacy is me not knowing the details of everyone else's life.
The original (US Supreme Court) right to privacy was about not getting birth control junk mail - it was about not having to read some interest group's anti-abortion snail-mail spam.Privacy is not a laundry list of checkboxes. Privacy is not a band-aid to be applied after you totally fuck it up.
Pacifica has a slight advantage in that it supports ASIDs (Address Space IDs, see your OS textbook's section on page tables), a long-overdue x86 feature. But even theoretically, that's not going to make up the difference.
Incorrect. Read the specs, and you'll see that VT's original spec makes no mention of shadow page tables and SVM lists it as an implementation-dependent feature. BTW, implementation of nested page tables (AMD's version) was slated for RevF, but slipped and last I saw (from The Register) was slated for RevH. It's on Intel's road map, I don't know how far out.
Maybe if they didn't contract out CD/DVD burning to the lowest bidder - if they'd spend a few more dollers getting the physical media from a company that takes security seriously - they wouldn't get stolen in pre-production?
Seriously. I see whining about how pirates beat the real thing to market? That shouldn't happen - and it's the manufacturer's own fault if it does. (Yes, the pirates are doing something illegal, it would be nice if law enforcement got them ... but any sane manufacturer knows that a certain amount of illegal skimming of the business will occur which law enforcement cannot clean up in a timely manner, and factors the waste in as cost of doing business). The faster to-market time is a problem that can be (easily!) solved with money - because the piracy market is clearly costing them more than the extra security would. Of course, instead of fixing the problem, we now get to be audience to the time-honored game of Blame Someone Else.
AMD offering with comparable RAM size: 2xOpteron 280, 114K thoughput, $2.99/unit cost, 32-bit OS, available May5 2006.
I looked for, but did not find, any 64-bit OS vs 64-bit OS comparisons (they only have 64-bit on 4-way Opteron, which isn't fair), this is unfortunate as the larger address space should make a real difference in TPC benchmarks. Also, the AMD ones are on 280s, AMD has 285s with larger caches now.
Difference in raw score is impressive though. It's a race ... can DDR2 + RevF improve Opteron enough in the six months before "availability" of Woodcrest?
Note that TPC numbers are usually price/performance; already, AMD is in a dead heat (if not ahead) here, and then factor in the six month release date difference. Hmm... looking at the numbers, the best 2xdual-core Xeon system reached $3.28/unit cost, Woodcrest made it to $2.99/unit, AMD 2xdual cores reach $2.73 (on a 128GB mem config) and 4xdual reached $2.13. Well... Intel is finally in the right ballpark for cost/performance! Now if only they had a pre-production 4xdual to show off?
Thanks for the link. Most interesting.
- Comparing FB-DIMM to DDR. FB-DIMM has something like 4x the bandwidth, and isn't even available outside Intel OEM samples. AMD is moving to DDR2 real soon. Comparing pre-production Intel parts to half-year-old AMD parts isn't benchmarking. It's PR.
- The benchmark list is mostly home-brewed. A hacked-together transaction processor (when there are industry standard ones out there for comparison - TPC numbers would be ideal), and RSA crypto optimized for the Intel processor.
- Their SAMP benchmark and portgresSQL benchmark are worthless (they dropped to single-socket for them). The only common ones on the list are specInt and specFP - both single-processor benchmarks that don't show scalability.
- The second link is a well-known example of Anand running a benchmark and discovering severe performance problems (i.e. mysql scales very poorly with more Opteron processors due to a mysql bug) - then still proclaiming Intel's huge victory.
Woodcrest is faster in single processor configurations. Duh - it's a preproduction model compared to AMD's 3-year-old design. These benchmarks ultimately say NOTHING about multiprocessor configurations - I have yet to see any useful 2-socket benchmarks.Please try to separate XenSource from the Xen community. Many of us don't work for XenSource and many of us think that XenSource does stupid things (this being a good example).
Fair - and in hindsight, I should have noted that distinction, apologies. (That particular MS/XenSource alliance happens to be at the top of my stupid list ... it hurts Xen, XenSource, all other virtualization businesses (via FUD), and ultimately helps only Microsoft).
I actually don't like VMI either. I still believe the hypervisor should be hidden - if the OS wants a virtualized timer, it should use a paravirtualized device driver, the API for which is independent of the hypervisor's core interface - but I don't think that loading a ROM is the way to load an interface. It's re-inventing BIOS. Frankly, I don't think there is a good solution. And once the CPU vendors get their acts together and actually virtualize the MMU (yup, they virtualized the CPU but not the onboard MMU, VT/Pacifica v1 is as weak as a 286) then the pressure on paravirtualization decreases as the performance advantage disappears. (Device paravirtualization is still needed - but that's easy! And the ground is ripe for competition in the feature set of an emulated device.)
VMware went to OLS and presented a paper demonstrating a VMI interface that runs either Xen or VMware at the same speed as the Xen interface. Xen has never tried to run on a VMware hypervisor, but XenSource went and signed a deal to run on the (future) Windows hypervisor. My opinion is that Xen is a bunch of hypocrites: they complain about how VMware isn't open, then go sign a deal with the least open company of all. Of course, I'm biased.
Xen wants VMware to adopt the Xen hypervisor interface. This is impossible. The Xen interface is too tightly coupled to the Xen hypervisor; it's missing pieces that are necessary to run the VMware hypervisor at reasonable performance. VMware doesn't really care which interface actually proliferates (as in, there will be a layer of interface glue regardless), so long as the interface is good enough. Xen's interface is not good enough. As of two weeks ago, Xen and VMI were the only two interfaces out there.
Greg K-H's gripe with VMware is that the kernel module isn't open source. Yes and no (I don't want to argue - the code is open but not GPLed), the point is that he's spending more time complaining about Xen and VMware than it would take to actually mediate the problem. (Which, thankfully, someone else is doing instead, with paravirt_ops).
Finally: I saw more pot-shots about being unable to benchmark VMware in the original article. That changed several months ago, benchmarks are now allowed by EULA. Certain companies ought to stop spreading FUD...
The Linux community does a good job of getting reasonably clean code into Linux. But in the process, they have adopted a horrific Not Invented Here complex - getting new code into Linux is a multi-month process at best (and multi-year if there's not a core kernel hacker championing the code). Windows is sufficiently modular that it's just a matter of loading a new driver - sometimes the new driver is good and sometimes it's crap. But Microsoft doesn't demand that developers run only officially blessed sources (module non-GPL tainting), receive two tons of junk mail, and get flamed by seven people with three mutually contradictory gripes, two of whom are flaming only for political Code Wants To Be Free(tm) reasons.
Windows drivers got much better when they started getting more user-generated bug reports by providing automated tools to collect such reports. (Admittedly, an approach started by Mozilla.) Open source code has nothing to do with it. And the Linux community would do well to learn from that example.
*blink*. VMware could run Windows when it first started shipping products eight years ago. It's Xen that has only been able to run Windows in the past few months, with VT chips. And Xen has conspicuously NOT published any benchmarks of that configuration - which leads me to believe performance sucks. Are you talking about paravirtualization? Fun fact: after VMware released their VMI patches to LKML, the very next release of Xen patches included several interfaces cloned directly from the VMware interface.
Yup, that's what it takes. But when you think about it, WoW64 (running 32-bit apps on Windowx x64) or running 32-bit apps on Linux do the same thing, and take the mode switch on every system call. It's not all that expensive ... a few thousand cycles ... and world switches are less common than context switches.
That said, memory benchmarks are more indicative of general workloads (not games). And, more importantly to me, memory benchmarks (and I/O benchmarks, which won't vary AMD/Intel) correlate strongly with perceived latency. I've always found a responsive, high-throughput system more important than straight-line game performance - though many prefer games.
Re: price/performance, AMD is dropping their price WHEN Intel chips come out ... let's talk about price then.
Re: FB-DIMM, they have the same problem as Rambus: latency. The only way to counter latency is large cache.
Yes, Woodcrest gets more bandwidth with Bensley architecture ... you see the part about FB-DIMMs? I sense another RDRAM fiasco here... Intel isn't going to have a good multiprocessor bus for a long while yet.
But the point is about Core 2 Duo. And the benchmarks insist on comparing against "AMD's greatest" (single core) - how about an X2 5000? Nope, I can't find such a review (after reading 10 FX-62 reviews). And - bluntly - I'm going to ignore any review that doesn't compare BOTH an FX-62 AND a X2-5000 against a Core 2 Duo. Why? Because it's blindingly obvious that the fastest AMD chip could be either of those two depending on the benchmark ... 2.8GHz vs dual 2.6GHz ... yet reviewers don't even try. It's lousy benchmarking.
- Core 2 Duo is faster than AMD for raw CPU. (Yes, this from a die-hard AMD fan)
- Power-consumption, the brands are (finally) about at parity.
- AMD's single processor-based advantage is memory: main memory access is still faster via on-chip memory controller. Admittedly, not worth much. BUT...
Criticisms.- I STILL have yet to see apples-to-apples comparisons. I'm pleased that these benchmarks are finally pitting DDR2 memory against DDR2 memory, but then they go and run a single-core AMD chip against a dual-core Intel chip. AMD single-core is a tiny bit faster per core than an AMD dual core, but single vs. dual makes a difference. Lousy benchmark design, folks.
- All the AMD benchmarks I saw were on nforce4 MBs
... AMD chips are up to nforce5 now (I've had one for the past two months). Yet the Intel MBs are using nforce5-generation chipsets. Again, lousy benchmarking!
- No analysis of the source of differences. Architecturally, Intel has 4-way issue vs. AMD's 3-way issue and Intel has 4MB L2 vs. AMD's 1MB L2. Now, AMD moves to a 65nm process later this year and their caches are going to come up to size (Intel has always had larger caches); I expect AMD's next core to bump issue width up to 4-way later this year or early next year. So we really don't know if Intel's architecture is any better or not - we really have to wait until AMD matches these easier-to-adjust features, which I expect to take ~6 months.
I'm still a fan of AMD, and I'm still going to buy AMD. Why? These benchmarks didn't show it, but scale up the number of processors to 2 sockets (for a total of 4 cores) and AMD is going to kick Intel all over the map. In short, AMD's system architecture is still more advanced than Intel's, and that means more *to me* than the processor's actual speed.Using CPU usage as a metric is as falicious as using raw GHz and claiming a Pentium 4 is the fastest chip out there. It does make a difference.
The fact that some KDE fan chose a name that's already in use just creates confusion. Ah, the joys of the open source world.
Virtualization demands that you be able to run arbitrary code at the most highly privilaged level. (for the pedants, QEMU is an emulator and does not do this; KQEMU is a virtualizer and does have this access). VMware uses the same mechanism - look at the device drivers it installs (the source code is shipped on Linux) and you'll find very similar code. That said, any device driver you install can provide the same access; do you trust Acme Inc who made your network card or video card?
The only security risk is if someone was able to overwrite the binaries on disk that get loaded via this mechanism. I assume they get installed chown-root to protect against this, but I have never actually run Parallels to know.
Funny that I've been watching AM2 carefully for the past month, and only agree on "less mature". AM2 is not faster by itself, but it does open the door to DDR2 memory. Which means Intel went out of their way to compare an AMD on DDR memory with an Intel chip on DDR2, when Intel could very easily have set up the "equivalent" AMD system on DDR2. When they deliberately don't match memory technologies, I'm suddenly very suspicious of Intel's benchmark.
My socket-AM2 system has been stable - except for Tomb Raider, which does seem buggy (and I'm blaming graphics drivers for that). nForce4 is a buggy chipset period, I don't see how that is any advantage at all.
I expect Intel to jump ahead with their Core design, and then AMD to make up much of the difference with K8L later this year. But on the server side, AMD is going to eat Intel's lunch for a long while yet.
And while I'm at it ... take a second to reread your post. It's FUD, pure and simple. We're used to FUD that says 'proprietary is safer', now we're starting to see FUD that says 'OSS may die, give us your support'. I happen to like OSS, make use of OSS in my everyday life, but being pulled into politics because of FUD does not appeal to me. And I realize you aren't trying to pull me in, but you are using the same rhetoric as people who are.
AMD's x86-64 does have segment limits (RevD and later), at the request of VMware. Also, AMD's Pacifica introduces ASIDs (Address Space IDs) into the TLB (RevF and later). It's x86, finally learning from all the other processors out there...
So yes, the GPL is a license agreement. It basically says, "by looking at this code, you agree that any work you do in this area will be GPLed". You apparently either aren't in the same market as GPLed software, or don't mind GPLing your work; I happen to feel it's a restriction on my freedom, so I go out of my way to avoid touching GPLed code.