95W CPU in CPU intensive applications = 95W all to CPU
To increase performance by a means that is affordable and known possible. It's not like anyone can magically make faster single threaded processors, by making them bigger and hotter. Those properties are the consequences of making them faster, because with slow memory, faster basically means being able to perform more complicated state changes in parallel over some period of time.More cores? Why do we need more cores?
Quicksync is an ASIP. It's only good for transcoding quickly. The GPGPU is good for performing vector operations over a large serial data stream. The CPU needs to be good for anything that fits on the tape. They are not swappable. Fixed-function hardware is faster at what it is made for, being simpler due to not having to do much else. GPGPU is somewhere in between the two.One thing that concerns me about Intel and AMD is that they promote and/or use additional non cpu technologies to do tasks that were originally performed on the cpu. In the case of AMD it is the gpu that will replace cpu cores for transcoding.....with Intel it is "Quick Sync".
Yet they want to sell us on the idea of more cpu cores?
Sure, but what about paying all the engineers to do the R&D? R&D costs a lot of money not just because implementing the final design is tedious, but because they will also need to verify what good ideas won't work for them, and what ideas that look good on paper suck in reality. The cost and time needed keeps going up and up and up, because it is not easy to do. It can be done, and Intel is making their CPUs ever faster per clock, but they can't just make a bigger one and watch it go really fast. Rather, they can spend a ton of money, and make one a bit faster, and watch it be bigger and maybe hotter. But, hotter means slower, today, which only adds to the difficulty.This makes me wonder what is going to happen with future Intel enthusiast sockets (ie, LGA 2011 successors)? Are we going to see those turn into "many core" arrangements without IGP? <----Just wondering how many people are going to want "many core" ATX towers if other (non cpu) techs are trying to obsolete this concept?
Surely Intel has a much higher IPC "non mobile" CPU core on the horizon (specifically for the enthusiast socket)? With these small nodes they certainly have the silicon die space to pull this off if processor design does not include IGP.
AMD can't sell the levels they have now (not much, anyway). They probably have one too many, and if they stick with the x86 server market (please do, please do, please do), should probably drop down to one server socket and be done with it.Before we say the market won't pay more, I'd like to see some analysis done on the potential for adding an additional level of AMD x86 Server products.
SMT offers very little, thus won't count as anywhere near a whole set of execution units. Even now that Intel has gotten HT working very well, typical gains from using it are <20%, and OLTP and OLAP are just the sorts of work where it may be eschewed in favor of per-thread performance. Also, again, per-core licensing doesn't matter to the overwhelming majority of the market.One thing I noticed in my brief reading of "per core" server licensing is that adding additional threads with SMT does not count as additional cores. For example, a large/wide high IPC AMD CPU core with four way SMT would still count as only one core.
http://en.wikipedia.org/wiki/Alpha_21464What I feel is needed is higher IPC design with greater width (with the appropriate compensations engineered into the CPU to make design work).
I could have sworn it was 6, which is closer to 2, but still, no. AMD brought the Hammer down, and COTS won. X86 got the RAS it needed to hang with the big boys, Linux became a serious sever OS (Linux/FOSS greatly removes hardware/software lock-in, benefiting X86 and ARM), and now it is too late*.With Poulson Itanium increasing to a whopping 12-wide, maybe Intel will permit this change to happen?
X86 got the RAS it needed to hang with the big boys
I think explicit support for logic fault checking is still IA64-only. Every other feature that even might be useful is on the high-end Xeons, and most of those are supported by RHEL.I once read a passage talking about Nehalem-EX RAS said that Nehalem-EX support some RAS features that were once only belongs to Itanium. But they do not support ALL RAS features. I don't know wether Westmere-EX is still the same.
Oh really. That sounds like IA64 is not that useful now.I think explicit support for logic fault checking is still IA64-only. Every other feature that even might be useful is on the high-end Xeons, and most of those are supported by RHEL.
Enterprise is for businesses who are happy as can be to pay a mint, as long as it works, and has every feature their DBAs asked for. Smaller businesses, who can't afford that, but might want to scale out, are going to go FOSS from the start, if they have any intelligence, so they will be irrelevant to SQL Server's licensing schemes.
Actually the one who told me that 4-core verson of Haswell will go back to 95W claims that the 18W difference from IVY is caused by the new IGP in Haswell...
Sure, but what about paying all the engineers to do the R&D? R&D costs a lot of money not just because implementing the final design is tedious, but because they will also need to verify what good ideas won't work for them, and what ideas that look good on paper suck in reality. The cost and time needed keeps going up and up and up, because it is not easy to do. It can be done, and Intel is making their CPUs ever faster per clock, but they can't just make a bigger one and watch it go really fast. Rather, they can spend a ton of money, and make one a bit faster, and watch it be bigger and maybe hotter. But, hotter means slower, today, which only adds to the difficulty.
It would make me a bit sad if billions in R&D is spent trying to eek out gains within some artificial database licensing restrictions rather than pursue much more productive avenues of development. Not saying it couldn't happen but it seems licensing is the more malleable of the two.
AFAIK, the general concept I am thinking about shouldn't make for a less efficient desktop CPU core.
What I feel is needed is higher IPC design with greater width (with the appropriate compensations engineered into the CPU to make design work). With Poulson Itanium increasing to a whopping 12-wide, maybe Intel will permit this change to happen?
The main goal would be a higher end x86 quad core server. The E-class desktops are just a sub market.
Oh, no it does. Sandy Bridge had a limited gain because rather than expanding all execution resources without thought they decided to enhance those that brought big gains, to increase efficiency. Just increasing the amount of decoders don't gain you anything, because other parts are holding you back. You need to expand everything like memory execution units, out of order resources, then you are back at the mercy of Pollack's rule.
What I feel is needed is higher IPC design with greater width (with the appropriate compensations engineered into the CPU to make design work).
Emulating X86 is in our future.
CPU architect said:The next step is to do even more work per instruction. This can be achieved by executing AVX-1024 instructions on the existing 256-bit units, in four cycles. The throughput remains the same but the instruction rate is reduced so the power hungry front-end can be clock gated for 3/4 of the time.
Emulating vs clock gating front end components? Which approach is more efficient? (I have no clue , but I thought I would include this post from CPU architect for the sake of discussion)Emulating X86 is in our future.
http://forums.anandtech.com/showpost.php?p=32630722&postcount=17
Clocking gating the front end.....for power savings. Essentially with this type of strategy we begin to see the beginnings of micro managing heat around within a cpu core.
Maybe this step could be taken one step further? Maybe each time only a single decoder is needed.....that decoder would not be used again till the other decoders got their fair share of the next tasks?
Furthermore, with respect to work per instruction being increased....I think that idea meshes very nicely with the idea of micro-managing heat within the cpu, but don't we still have the problem of doing work in a silicon space about 1/2 the size of the previous space when a new node is used? Maybe a work around to this is to over-provision various decoders, execution units, etc. <----Then program the CPU so each one doesn't get over used in comparison to other identical units?
Do you see what could be happening with our CPUs as these nodes progress? Silicon area decreases by 50%, but power efficiency only increases by 25%. Essentially we run into the problem where just keeping the same single threaded performance (As the old node) becomes an accomplishment in itself! <----This is yet another reason why some kind of strategy involving wider cores for these small (14nm and beyond nodes) makes a degree of sense to me.
Reinventing the wheel happens all the time, for just that sort of reason (we can do it cheaper, we can do it better, we won't be able to afford many per-server licenses if we start growing, we don't want to worry about future upgrade costs, etc.). Generally, though, such applications are very expensive, just like the commercial DBs, and people with appropriate certifications for said applications and/or DBs will be more expensive than not (or the expense of the application includes good support), so it will work out. If the money is there, and it would have a high likelihood of causing a result of greater (or just quicker) profit, then it is likely worth paying for.Yeah but certain Applications require a certain Database, meaning it will run on Oracle only and not MySQL. And in certain niche markets there aren't any alternatives besides inventing the wheel yourself.
It's time-consuming and expensive not merely to deisgn all the common x86 CPUs, but then to extend that to a good server chip. Some of the lower Xeons are just desktops w/ ECC, but the upper end have started integrating other useful low-level Itanium features, like multi-level ECC for registers, and logic paths much more resistant to soft errors. Now, is there a lot of profit, there? Sure. Too much? Maybe, but AMD would need to have high-end competition again to make a difference in the prices, and it doesn't look like they are on their way towards doing that again. Personally, I'd rather see the RAS from the EX trickle down to every Xeon (maybe not all of the A and S parts--hot-pluggable CPUs, RAM, and cards can stay in the high end), than worry about a paying $2k+ per CPU for a 4P system that is already likely to be $10k+ before the CPU, just in purchase costs (operating costs are likely so significantly exceed that).I completely agree with you about paying engineers to design x86 CPUs. That is money well spent!
So this is why I brought up MS SQL 2012 Enterprise licensing changes....as a start.
Hopefully the necessary experts, engineers and number crunchers can get together and tame this dragon which is the high end x86 CPU Budget.
I think it's a questionable tradeoff to widen the vector x86 extensions much more. You're spending a lot of energy running operations speculatively out of order in an x86 core...if you have a task that parallelizes to 1024 bits, does it really not fit much better on a proper vector machine like a GPU, which can hide latency in an energy-efficient way? (What I'm asking is, are there that many tasks that parallelize to more than 256 bits that don't go all the way to GPU widths? Each time you double the CPU width you're helping fewer and fewer tasks). I wouldn't dispute a claim that Intel is going to do it anyway, but they have their own motivations that don't always lead them to the best technical solution.