On 04/14/2013 01:55 AM, Pandu Poluan wrote: > > On Apr 14, 2013 1:42 AM, "Michael Mol" <[email protected] > <mailto:[email protected]>> wrote: >>
[snip] > > What I meant was: given 4 physical AMD cores (but only 2 FPUs, courtesy > of AMD's Bulldozer/Piledriver arch) vs 4 virtual Intel cores (2 cores > split into 4 by Hyperthreading), I undoubtedly prefer 4 physical ones. > > (Of course if the Intel CPU has 4 pphysical cores, it should be compared > with an 8-core AMD CPU). > > I had some lively discussion on AMD vs Intel *for virtualization* in the > Gentoo Community on Google+, which referenced a thread on ServerFault. > The conclusion was: Intel CPUs (provided they support VT-x) can run > baremetal virtualization as well as AMD, in the majority of cases. > > It's the minority of cases -- edge cases -- that I'm concerned with. > And, lacking the money to actually buy 2 complete systems to perform > comparison, I'll take the safe route anytime. > > Yes, Intel's top-of-the-line processors might be faster than AMD's, but > the latter is cheaper, and exhibited a much more 'stable' performance > (i.e., no edge cases to bite me later down the road). > > That said, I read somewhere about the 'misimplementation' of some > hypercalls in Intel CPUs... in which some hypercall exceptions are > mistakenly handled by the Ring 0 hypervisor instead of the Ring 1 guest > OS, thus enabling someone to 'break out' of the VM's space. This > misimplementation is exploitable on KVM and Xen (the latter, my > preferred baremetal virtualization). That's actually very interesting. I hadn't heard about this. > >> > >> > I much prefer having 4 actual cores than 4 virtual cores (only 2 >> > actual cores); less chance of things messing up royally if I hit some >> > edge cases where Hyperthreading falls flat on its face. >> >> Whatever works. I'll note that AMD's piledriver core does something very >> complementary to hyperthreading. Where HT uses some circuitry to avoid >> context switching when changing whether a core is handling one thread vs >> another thread, Piledriver has a small number of physical front-end >> cores dispatching to a larger number of backend pipelines. It's a very >> curious architecture, and I look forward to seeing how it plays out. HT >> and Piledriver are conceptually very similar when you look at them in >> the right way...Piledriver might be seen as a more general approach to >> what HT does. >> > > True. The main complexity is when an instruction requires access to the > FPU, since there's only one FPU per two GP cores. This will somewhat > impact applications that uses the FPU heavily... except if they can > switch to OpenCL and leverage the embedded Radeon on AMD's so-called "APUs". > Intel's on-die GPGPU looks promising in that regard, too. As a guy who likes to do heavy bulk float crunching in HDR imagery, I'm looking forward to OpenCL improvements. >> Personally, I've enjoyed both Intel and AMD processors. Last I assembled >> a system, Intel's midrange offered more bang for the buck than AMD, but >> Intel's midrange part was also much more expensive. OTOH, AMD systems >> could be upgraded for piece by piece for much, much, much longer, >> whereas Intel systems tended to require replacing many more parts at the >> same time. >> >> That was about five years ago, though...I don't know exactly where >> things sit today. I'd start with the cpubenchmarking.net > <http://cpubenchmarking.net> CPU value >> listing, and find the best-value part that has the performance degree >> I'm looking for. >> >> http://cpubenchmark.net/cpu_value_available.html >> >> I might also cross-reference that page with this one: >> >> http://cpubenchmark.net/mid_range_cpus.html >> > > True. My desktop computer died on me about 6 months ago. It was 4.5 > years old at the moment of death. It had served me very well. > > That said, my brother had just purchased an AMD system (store-assembled) > with an FX-8350, and he said that it's faster than anything he's ever > used before, and he's used many high-end systems in his job (he's a > Petroleum Geologist, his line of work involves analyzing a HUGE amount > of data to find out the 'oil potential' of an area, to give his company > a ballpark figure on how much to bid for the exploitation rights to the > area). My "desktop box" has two Xeon E5345s. When I looked it up, I was amazed that the FX-8320 has *twice* the cpumark score as the E5345. (Still doesn't make sense to replace what I have, though; the difference in power bill would take a few years to pay for the parts.) The FX-8320 looks promising. Now if only desktop motherboard manufacturers would add IPMI... > >> If buying an Intel part, I'd be very, very careful to make sure that it >> supported all the features I want. I've been bit by that on this >> laptop...I had no idea it wouldn't have VT-x. >> > > I almost got bitten by this: My previous employer had wanted to purchase > a lot of new workstations. Luckily before the PO came out, I double > checked the specs. When I found out that the particular model we were > offered does not support VT-x, I immediately halted procurement and ask > the supplier to resubmit a quotation, but this time specifying that VT-x > support is required. > > (It's a long story, but we do use VirtualBox extensively. And running > VirtualBox without VT-x is an exercise in misery). Hey, I remember running VMWare on an Athlon XP 3200. I also remember that being *ffaast*, compared to qemu. ^^ > > But that was three years ago; perhaps the latest Intel processors for > the desktop today all support VT-x, I don't know... I expect i5s and up support VT-x. I think i3s are where you're likely to have problems.
signature.asc
Description: OpenPGP digital signature
