A Co-processor No More, Intel's Xeon Phi Will Be Its Own CPU As Well

An anonymous reader writes "The Xeon Phi co-processor requires a Xeon CPU to operate... for now. The next generation of Xeon Phi, codenamed Knights Landing and due in 2015, will be its own CPU and accelerator. This will free up a lot of space in the server but more important, it eliminates the buses between CPU memory and co-processor memory, which will translate to much faster performance even before we get to chip improvements. ITworld has a look."

Comments

Yee-haw no more

[vikingpower]

Moore's law is not coming back from the grave, or is it ?

Re:Yee-haw no more

[Joce640k]

a) It's not a "law"

b) It doesn't say that transistor counts will double every 18 months.

Re:Yee-haw no more

[Chas]

A) Stop being a pedantic dick.

B) Correct. The original 1965 paper observed that transistor counts were tending to double every year (12 months), which he later revised to every 2 years (24 months) in 1975.

What people are misquoting is the House corollary. That PERFORMANCE of microprocessors, due to increased transistor counts, and faster speeds, seems to double roughly every 18 months.

Re:Yee-haw no more

[Sockatume]

If you're going to nitpick, at least act like you want to educate people and aren't just being a smartass:

1) It's a law the same way Newton's Laws are laws: it's a simple quantitative relation which has held up very well over time.

2) a) In its original formulation it said that the number of components you could put on a chip at minimum cost (because you can always cram in more at higher cost) doubled ever year.

ii) In its later correction (he used only five data points in the first paper!) he revised this to every two years.

gamma) It was a head honcho in Intel who then concluded that such a relationship would double overall computer performance every eighteen months.

Given that the components of interest on a processor are transistors, I do not have any great objection to the generalisation that it's transistor counts that double and not all components.

Re:Yee-haw no more

[Joce640k]

1) It's a law the same way Newton's Laws are laws.

Newtons laws are based on real physical "laws". Not the same thing at all and definitely not "nitpicking".

There's a well know observation that's known as "Moore's Law", yes, but calling it a "law" doesn't make it one. There's a parable about grains of wheat on a chessboard which explains why. Anybody with a working brain can see that it can't hold for much longer. The laws of physics and mathematics will come into play soon (and they're real laws, not data trends).

Newton's laws? I expect them to hold until the end of time.

Re:Yee-haw no more

[Sockatume]

Newton's Laws are, at best, approximations to general relativity that are well-behaved on human timescales. They're quantitatively extremely good but that doesn't put them in another class from Hooke's Law, say, which only holds for a perfect harmonic potential, or Ohm's law, which falls down on similar length scales to Moore's law. That some of them used as the basis for physics and some aren't doesn't change the fact that they're all quantitative models for observed phenomena and have an equal stake to the 19th century's pretentious "law" label.

Re:Yee-haw no more

[Joce640k]

They're quantitatively extremely good

And will still be extremely good a million years from now.

Or a billion...

CPU embedded in GPU versus GPU embedded in CPU

[abies]

I thought that we already had GPUs embedded in CPUs. How embedding CPU inside GPU makes it so much different and breakthrough?

Re:CPU embedded in GPU versus GPU embedded in CPU

[Overzeetop]

Patents already cover most implementations of GPUs within CPUs. But the field is wide open if you start embedding CPUs in GPUs. It's like "on the internet," but with uprocessors.

Re:CPU embedded in GPU versus GPU embedded in CPU

[Sockatume]

There's no other component. (Pedantry: calling it a GPU is a misnomer as nobody really uses them for real-time graphics. You won't be playing Crysis 3 with one of these. It just happens that this kind of hardware came out of graphics silicon design.)

Re:CPU embedded in GPU versus GPU embedded in CPU

[TWX]

Turtles, all the way down...

Re:CPU embedded in GPU versus GPU embedded in CPU

[fluffythedestroyer]

GPU is important enough at least at a basic level but when you speak about servers... do we need them. I mean, I know microsofts next servers will have the optional GUI implemented and they will "try" to get away from the GUI and will recommend to work without it. I question the need for the GPU

Re:CPU embedded in GPU versus GPU embedded in CPU

[Anonymous Coward]

It's not just for drawing graphics. It can be used as a general computation platform.

As an example imagemagick supports OpenCL nowadays. So as an example if you have a webpage where images can be uploaded and you do some processing for them (cropping, scaling for thumbnails etc) you can get absolutely amazing performance on a server with GPU.

Re:CPU embedded in GPU versus GPU embedded in CPU

[Anonymous Coward]

It's hard to believe how shortsighted some of you people are... The GPU in the server has nothing to do with graphics (despite it being in the name), it is used for general highly parallel computations, and while traditional server software doesn't currently support it it is theoretically possible to accelerate traditional server applications such as databases using the GPU, and it has been actually demonstrated with PoC software.

Captcha: leverage

Re:CPU embedded in GPU versus GPU embedded in CPU

[gl4ss]

Hint: The "G" in "GPU" does not stand for "game".

Graphics? because that's what it stands for.

I guess some people are going to be calling them General processing units or some shit like that but frankly if they can't be bothered to call it a co-processor if that's what they want to call it they could do well with a punch to the groin.

Re:CPU embedded in GPU versus GPU embedded in CPU

[fast turtle]

kick those Ninja Turtles out of this discussion. They're not related to me.

Optionally

[Sockatume]

Knights Landing will be available as both an accelerator card and a standalone CPU with some sort of large high-speed memory pool on the die.

Fully Baked?

[DragonDru]

Good. The current generation Phi cards are a pain to administer. With luck the new generation will be more fully baked.
- very hot card, no fans
- depends on software to down throttle the cards (mine have hit 104C)
- stripped down OS running on the cards, poor user facing directions for the usage

Anyway, enough from me.

Re:Fully Baked?

[Junta]

I won't disagree about the awkwardness of MPSS, but the 'very hot card, no fans' is because it's meant only to be installed into systems that cooperate with them and have cooling designs where the hosting system takes care of it. For a lot of systems that Phi go into, a fan is actually a liability because those systems already have cooling solutions and a fan actually fights with the designed airflow.

Of course, that's why nVidia offers up two Tesla variants of every model, one with and one without fan, to cater to both worlds.

Re:Fully Baked?

[Anonymous Coward]

Xeon Phi also have variants with and without fans:

http://newsroom.intel.com/servlet/JiveServlet/showImage/38-5572-2661/Xeon_Phi_Family.jpg

Re:Fully Baked?

[kry73n]

maybe they will finally also remove those texturing units from the Phi

Re:Fully Baked?

[DragonDru]

Yes, I have run into the "over heat and fall off the bus" issue. I ended up having to depower (pull the plugs on the host system) the system entirely in order to get them to work correctly after that. On both of the systems I have setup Phi Cards, I had to update the BIOS and set the system fans to run full speed all of the time.
It would have been nice if the cards included their own throttling...

Frankly, the accelerator card is pretty dumb

[Anonymous Coward]

For a Phi, the selling point is about ease of programming. The memory model of the accelerator card is a pain in the ass, making development more difficult. This on top of the fact that the administration of those are pretty limited and annoying. MPSS is crap for everyone, and one of the critical differences here is that the standalone accelerator might not require Intel to be the linux distribution curator anymore (they frankly suck pretty hard at it).

Intel having a standalone variant pretty much obviates the utility of an accelerator card model for all but perhaps the tiniest usage and makes things far more simpler. Trying to get the same workload to work across Phi and main CPUs is, in practice, more about trying to make the best of an awkward heterogeneous compute situation. While you still can and will run jobs heterogeneous if you do have both Phi and normal Xeon nodes (e.g. a top500 run and... well not much else), it is done using more typical methods of MPI.

In short, this move pretty much let's intel focus on the pieces they *are* good at (making a decent processor) and get away from the stuff they aren't so good at (pcie hosted device, linux distribution design, etc).

Re:Frankly, the accelerator card is pretty dumb

[Sockatume]

So you think the accelerator card version is just a stopgap for customers looking to upgrade (rather than replace) their systems, and it'll go away in time?

80487 coprocessor all over?

[Anonymous Coward]

The 80486 was the first Intel processor with integrated coprocessor, coming at about €1000 (only know the DM price). There was a considerably cheaper version, the 80486SX "without" coprocessor (actually, the coprocessor was usually just disabled, possibly because of yield problems, and still took current).

One could buy an 80487 coprocessor that provided the missing floating point performance. Customers puzzled how the processor/coprocessor combination could be competitive without the on-chip communication of the 80486. The answer was that it did not even try. The "coprocessor" contained a CPU as well and simply switched off the "main" processor completely. It was basically a full 80486 with different pinout, pricing, and marketing.

It was probably phased out once the yields became good enough.

Re:80487 coprocessor all over?

[kheldan]

It was basically a full 80486 with different pinout, pricing, and marketing.

Intel also made an 80386/80387 "RapidCAD" chipset, that I managed to get a hold of at one point, and discovered that the 80387 was just a dud (which, according to Wikipedia, was there just to supply the FERR signal, to keep everything compatible with a real '387); the coprocessor was on-die with the '386 core, just like a '486.

Good multi-thread, bad single-thread

[Theovon]

These processors are like an Intel version of Sun Niagara, but with wider vector. Actually, from an architectural perspective Xeon Phi (Larrabee) is pretty basic. They’re an array of 4-way SMT in-order dual-issue x86 processors, with 512-bit vector units. I think one of the major reasons Xeon Phi doesn’t compete well with GPUs on performance is that legacy x86 ISA translation engine taking up so much die area. Anyhow, so if you have a highly parallel algorithm, then Xeon Phi will be a boon for performance.

But as we know, there are numerous very important algorithms that are not parallelizable.

Re:Good multi-thread, bad single-thread

[serviscope_minor]

These processors are like an Intel version of Sun Niagara, but with wider vector.

I thought the Niagara was a crazy-wide barrel process or sorts: it switches to a new thread every cycle with a grand total of 8 threads (per core). The idea being that if you've filled up all 8 threads, then each instruction can wait 8 cycles for a bit of memory entirely for free because it takes 8 cycles to execute.

The idea (not entirely realised sadly) was that for highly parallel workloads you get much higher aggregate throughput since you have far fewer memory stalls than a much faster single threaded core.

Neat

[RobHostetter]

I could see using this, whereas I couldn't see myself using the card version. If the cost premium is reasonable this could be awesome for image processing. I have an image algorithm I use CUDA for and moving the data around consumes almost as much time as processing the data. If I had this in my servers I would have flexibility and much greater performance with this solution. --Robert

i see a problem with this

[etash]

wouldn't an embedded in the cpu xeon phi version, lack the necessary GDDR4/5 which exists in the PCI-express card version with its 200-300GB/s of throughput, and be forced to just access the main computer RAM at about 40-50GB/s?

GPUs

[DrYak]

I don't know about Niagara's, but according to docs about Warps and half-warps, that's how Nvidia GPU run CUDA.

They keep cycling through 2 or 4 threads, to hide memory latency.
(Except that each thread it self runs on a wide SIMD instead of a normal CPU. So the final size of parallel execution [=threads] is the amount of wraps in parallel x size of the SIMD).