Hence why I compared it very carefully to IBM'S SMT rather than Hyperthreading. IBM SMT has componentsto handle each 'thread' while sharing common components (including FPU in SMT8 but isn't shared in SMT4). It isn't 8 threads in the hyperthreading sense, but neither is it 8 'cores' with respect to how any other CPU vendor calls things cores. IBM is the only other microprocessor vendor that has something that resembles the AMD design, and they do not refer to the components as 'cores'.

I haven't seen any FP intensive code work better than Ivy bridge equivalents (1 ivy bridge core =~ 1 piledriver module no matter what I tried with respect to running one or both of the 'cores'). Haswell of course can roughly double ivy bridge perf when avx2 can be put into optimal play.

AMD is sadly little more than a 'budget' player right now. Releasing inefficient designs to compete roughly with Intel. Though NetBurst was sadder, as you were expected to pay *more* for the crappy inefficient product than the rather good (for the time) Athlons. Here's hoping they get their stuff back.

Indeed, even after installing the software, upgrading is easy. Excepting some DRM crap that could fire if you change too much, but that is BS.

I am actually married and a father too. I can't disappear into a 'mancave' every day for hours on end or spend all our money on high end gaming equipment, but I don't catch flak for spending my time gaming for a short while many days and the occasional 'bender' of gaming. If I covered the house in gaming paraphernalia or something maybe, but as long as I don't go overboard on time or expense, there's no issue.

I'm not saying the IPC is netburst like, but that the overall performance characteristic is low performance relative to what the competition *would* be at '8 cores'. Just like a NetBurst 3.0 ghz would have been trounced by the contemperary AMD at 3.0 ghz (and even much lower), an '8 core' is bested by something with much lower core count. For example, in the url you cite, they effectively consider the FX 8350 as a quad core rather than 8 core solution for the performance to be comparable. This is with a workload that does not take advantage of AVX2 (which would have the Haswell parts pull well ahead of the competition). A quad core 4.1 ghz ivy bridge would have matched the '8 core' 4.1 ghz 8350. So if you get the '8 core' thinking 'twice as fast as ivy bridge quad core', that would be incorrect assumption that AMD is counting on marketing wise.

In short, AMD has '8 cores' that performs like 4 cores, but with heat and power characteristics more closely resembling 8 than 4 cores. Just like an Athlon at 2 ghz could match the performance of a Pentium 4 at 3 ghz, but with much less power/heat than the Pentium 4.

Why not actually try the games that you want and then decide if things are too slow at all, rather than listen to some people that will evangelize how cool new stuff is with impunity since it is not their money they are justifying spend on...

What could be pathetic is neglecting responsibilities or pissing away family savings on superfluous stuff. If one takes care of their responsibilities appropriately and is prudent in their spending, it doesn't really matter if a grown man plays computer games or watch telly tubbies or whatever they like so long as it doesn't screw up other people's lives.

If IBM did the processor, they would have called it 4 Core with SMT2. Basically you have 4 modules, with 2 of many of the components, but a lot of shared components. Notably, each of the 4 modules has a single FPU (so it's more like IBM's SMT8 versus SMT4 mode if you talk about their current stuff).

So it's more substantial than hyperthreading, but at the same time not reasonable to call each chunk a 'core'. I think it behaves better than Bulldozer did at launch *if* you have the right platform updates to make the underlying OS schedule workload correctly, but it's still not going to work well (and some workloads work better if you mask one 'core' per module entirely).

Basically, it's actually pretty analogous to NetBurst. NetBurst came along to deliver higher clock speeds since that was the focus of marketing, with some hope of significant workloads behaving a certain way to smooth over the compromises NetBurst made to get there. the workloads didn't evolve that way and NetBurst was a power hungry beast that gave AMD a huge opportunity. Now replace high clock speed with high core count and you basically have Bulldozer/Piledriver in a nutshell. I'm hoping AMD comes back with an architecture that challenges Intel agin, just like Intel came back from NetBurst.

I don't think this stuff is expected to go any faster. To be fair to microsoft, the frequency of updates is already pretty respectable (latency and quality on the other hand...). The rumors are that MS will start mixing in functional changes more. Of course this seems like a mistake, their competitors really aren't mixing it up much on the fundamental level anymore (Google churned pretty hard because they needed too, but Jelly Bean seems to have marked where they broke out the functcion).

Microsoft is only bested on the 'faster' (latency and frequency) front by Linux Desktop distros, and see how much that has made people in the wider market care. It's a shame because Android updates are pretty infrequent *and* get deployed extremely slowly. This means a great deal of mobile Chrome browsers continue to have SSL vulnerabilities, mitigated somewhat by most reputable servers having addressed it on their end. If MS was botching a security update that badly the community would be all over them. Though again, the wider market doesn't really care except to be pissed at having to deal with frequent update related interruptions (where again I think linux desktop distros seem to have the right balance of availability but not being so heavy handed).

I don't download that stuff, but as a netflix user who also has DVD rips and DVR recordings that I manage under XBMC, I can easily understand the appeal of having the content locally and in a form that can be integrated with media from other sources.

Netflix outages are frustrating. When it is up, sometimes I can't stream the best quality in real time. Sometimes the client has to be kicked in the head for no apparent reason to make it stream at all or stream the best reasonable quality. Any seeking takes a relatively long time, and won't seek with the same precision as xbmc will. It does an admirable job of a UI, but it's not my favorite. I wish the streaming service could be mated with third party applications better to allow more than just netflix's concepts of show organization and playback control to work with their content, as well as the ability to prebuffer the highest quality regardless of my current conditions. I also find it excessively wasteful if I feel like rewatching something and knowing it redownloads it every time, which is where I would like to jump to 'just buy the damn thing' were there a convenient legal option without DRM.

That all said, they still have a great deal better software experience than amazon prime...

I had pretty much given up all hopes of DRM-free video via legitimate channels, even as music is pretty much DRM-free exclusively.

I'm not getting my hopes too much, but like DRM-free music before it, I'll be very eager to give them my money instead of buying DVDs with it.

I'm however fully expecting like eBooks, the DRM-free selection will remain sad and pathetic.

As virtualization became 'cool', people said 'look how many instances you can cram on these gigantic boxes'. This quickly became 'how many instances am I going to lose if this goes down' or 'how many do I have to live migrate to service this thing?'. The cost advantages of scale with a larger box are quickly offset by practical issues. As such, if you need that much memory in a single system, those sort of boxes are still very valued (in-memory databases and some particular sorts of modeling for example). If the workload naturally fits into more nodes of smaller size, it frequently makes sense to opt for the higher node count. There is of course different break points depending on judgement calls, but most places seem to think of two sockets as about the sweet spot.

So you have a quad-core with hyperthreading.

But in general I agree with the sentiment. I do think comparing random whitebox with the big POWER boxes fails to capture the whole reality, but it's easy enough to note that alongside that random whitebox there are enterprise grade suppliers using the common architecture. A person able to slap together a whitebox x86 may not be as useful for business continuity on his own left to those decisions, but those same skillsets can be employed toward an enterprise solution while staying in the x86 family. POWER does not scale down yet, and that is one of IBM's missions. I'm skeptical they will succeed, but at least they acknowledge ecosystem as a key need.

It is a market segment that is seeing growth, and the hype machine has gone into overdrive under the assumption that anything that grows will grow indefinitely overtaking anything it conceivably could in its path.

The reality like all other times before is that it might get more adopted than it should before receding to the appropriate amount as it plateaus as the hype gets done. Thin clients have been around for ages even as the hype behind them has erupted and died out multiple times. They clearly have their role but it is clearly not the end-all, be-all that these companies bill it as.

The attack is more precise. Need to know precisely when to pop up the input form of interest. Sure this information could allow them to disambiguate the context so that a random memory change in a random app doesn't trigger a false positive. Of course the whole point was also to demonstrate how well they could do without any remotely suspicious permissions.

So in the OS side, at the very least it seems that an obvious indication of application focus change would go a long way toward making this seem not right.

On the application side, I think applications that are likely to get sensitive information should always display a consistent randomized watermark in their application. Let's say they make an 'always at the top' bar with two randomized words. With that, the sensitive input forms that try to be phished will look incorrect because the watermark suddenly changes.

Of course, that comes with its own headaches and negates some of the benefits of a VM architecture. Paravirtualized networking is however pretty adequate for most workloads.

It's not like you have to do VM *or* baremetal across the board anyway. Use what makes sense for the circumstance.

In my experience, KSM hasn't helped as much as it promised. It depends heavily upon the workloads. It also impacts memory performance. If things are such that KSM can be highly effective, then a container solution would probably be more prudent.