Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Larrabee ISA Revealed

Soulskill posted more than 5 years ago | from the popping-the-hood dept.

Graphics 196

David Greene writes "Intel has released information on Larrabee's ISA. Far more than an instruction set for graphics, Larrabee's ISA provides x86 users with a vector architecture reminiscent of the top supercomputers of the late 1990s and early 2000s. '... Intel has also been applying additional transistors in a different way — by adding more cores. This approach has the great advantage that, given software that can parallelize across many such cores, performance can scale nearly linearly as more and more cores get packed onto chips in the future. Larrabee takes this approach to its logical conclusion, with lots of power-efficient in-order cores clocked at the power/performance sweet spot. Furthermore, these cores are optimized for running not single-threaded scalar code, but rather multiple threads of streaming vector code, with both the threads and the vector units further extending the benefits of parallelization.' Things are going to get interesting."

cancel ×

196 comments

Sorry! There are no comments related to the filter you selected.

I don't care for Mexicans (-1, Flamebait)

Fanboy Fantasies (917592) | more than 5 years ago | (#27456089)

No, not at all.

Hackers. (0)

Anonymous Coward | more than 5 years ago | (#27456469)

Was the best movie of all time.

Missed it by *that* much (0, Troll)

Anonymous Coward | more than 5 years ago | (#27456095)

If developers are too stupid to code for it, it won't go anywhere. This is sounding a lot like the PS3 architecture in complexity. Parallelism is not that hard to deal with, but you have to know what you're doing. Sadly, few do. Try again in ten years.

Re:Missed it by *that* much (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#27456147)

If Indian coders are too stupid to bathe and use deodorant, their code won't go anywhere. This is sounding a lot like the Cyrix architecture in complexity. Parallelism is not that hard to deal with, but you have to know what you're doing and not stink like you knock buzzards of shit-wagons. Sadly, few do. Stinkies - try again in ten years.

Meanwhile, the few leftover American companies who are smart and un-Jewish enough to pay the extra 2 cents to hire whites will get code that works. Remember Windows Bangalore Edition a.k.a. Vista.

Re:Missed it by *that* much (4, Insightful)

SlashWombat (1227578) | more than 5 years ago | (#27456177)

It appears that this could well improve the speed of lots of different operations. A definite boon for graphics like operations, but also a lot of DSP (audio/maths)stuff can benefit from these enhancements. It would also appear that general code could easily be sped up, however, compiler writers need to get their collective arses into gear for this to happen.

However, give the average developer more speed, and all that gets produced is more bloat with less speed. If you watch large teams of programmers, the managment actually force the developers to write slow code, claiming that maintainability is more important than any other factor! (smart code that actually executes quickly is generally too difficult for the dumb-arsed upper level (management) programmers to understand, and is thus removed. Believe me, I've seen this happen many times!)

What? Is 15GB that much for a base OS install? (4, Informative)

symbolset (646467) | more than 5 years ago | (#27456217)

Your post can be summarized as: Intel Giveth; Microsoft taketh away. That's been the formula for far too long.

And that period is almost over.

Re:What? Is 15GB that much for a base OS install? (0)

Anonymous Coward | more than 5 years ago | (#27456233)

It is over already, Gates retired, remember?

Re:Missed it by *that* much (1)

SQL Error (16383) | more than 5 years ago | (#27456533)

Fast code that doesn't work is not all that useful.

Except in search engines.

Re:Missed it by *that* much (4, Funny)

somenickname (1270442) | more than 5 years ago | (#27456605)

It appears that this could well improve the speed of lots of different operations. A definite boon for graphics like operations, but also a lot of DSP (audio/maths)stuff can benefit from these enhancements. It would also appear that general code could easily be sped up, however, compiler writers need to get their collective arses into gear for this to happen.

Yeah, and while they are at it, I hope they finally get around to fixing that damn segfault bug. It's been around for YEARS.

Duh (4, Interesting)

symbolset (646467) | more than 5 years ago | (#27456193)

That's what libraries, toolsets and custom compilers are for. If the problem was just silicon we'd have Larrabee by now. What's holding up the train is the software toolchain and software licensing issues.

Don't worry, though. On launch day the tools will be mature enough to use, and game vendors will have new ray tracing games that look fabulous on nothing but this.

I'm hoping the tools will be open but that's a long bet. If they are, Microsoft is done as the game platform for the serious gamer and Intel will make billions as they take the entire graphics market. Intel will make hundreds of millions regardless and a bird in the hand is worth two in the bush, so they might partner in a way that limits their upside to limit their downside risk. That would be the safe play. We'll see if they still have the appetite for risk that used to be their signature. I'm hoping they still dare enough to reach for the brass ring.

Re:Duh (1)

ThePhilips (752041) | more than 5 years ago | (#27456501)

Tools would mean dick and it would take long time for developers to actually adopt such tools to exploit the architecture.

As an example, take recent Sun's highly-multi-threaded CPUs - T1 and T2. Benchmark team ran our software (essentially message processing) on the CPUs and it is dog slow - unless you disable the CPU multi-threading. On other hand Java, have seen good boost to performance: because Sun's JIT already can on-the-fly optimize code for such architecture.

It is a long road for Larrabee before general acceptance. Let's just that Intel wouldn't make same mistake [wikipedia.org] twice.

Re:Duh (2, Insightful)

fuzzyfuzzyfungus (1223518) | more than 5 years ago | (#27457573)

We should remember that, at least at first, Larrabee is being pushed as a GPU, not a CPU, and all contemporary GPUs are already substantially parallel. If anything, intel's is (unsurprisingly) by far the most conventionally CPU-like of the bunch.

Re:Missed it by *that* much (4, Informative)

julesh (229690) | more than 5 years ago | (#27456697)

If developers are too stupid to code for it, it won't go anywhere. This is sounding a lot like the PS3 architecture in complexity.

There are several problems with PS3 programming that don't apply to Larrabee:

* Non-uniform core architectures. Cell processors have two different instruction architectures depending on which core your code is intended to run on. This causes quite a bit of confusion and makes the tools for development a lot more complex.
* Non-uniform memory access. Most cell processor cores have local memory, and global memory accesses must be transferred to/from this local memory via DMA. Larrabee cores have direct access to main memory via a shared L2 cache.
* Memory size constrains. Most cell processor cores only have direct access to 256K of memory, so programs running on them have to be very tightly coded and don't have much spare space for scratch usage.

Any application that's reasonably parallelisable is going to be pretty easy to optimize for larrabee. Most graphics algorithms fit into this category.

An architecture named after a Get Smart character? (1)

Eternal Vigilance (573501) | more than 5 years ago | (#27456107)

Bet they've got some serious CONTROL structures to keep things from getting too KAOTIC....

"Would you believe a GOTO statement and a couple of flags?"

Re:An architecture named after a Get Smart charact (1)

MichaelSmith (789609) | more than 5 years ago | (#27456141)

Bet they've got some serious CONTROL structures to keep things from getting too KAOTIC.... "Would you believe a GOTO statement and a couple of flags?"

How about a while loop and a continue statement?

Re:An architecture named after a Get Smart charact (0)

Anonymous Coward | more than 5 years ago | (#27456299)

I don't think so.

Where continue may fail with a nested loop (4, Informative)

tepples (727027) | more than 5 years ago | (#27456611)

"Would you believe a GOTO statement and a couple of flags?"

How about a while loop and a continue statement?

In C, a continue breaks out of only one nested while or for loop. If you're in a triply nested loop, for example, you can't specify "break break continue" to break out of two nested loops and go to the next iteration of the outer loop. You have to break your loop up into multiple functions and eat a possible performance hit from calling a function in a loop. So if your profiler tells you the occasional goto is faster than a function call in a loop, there's still a place for a well-documented goto.

C++ code can use exceptions to break out of a loop. But statically linking libsupc++'s exception support bloats your binary by roughly 64 KiB (tested on MinGW for x86 ISA and devkitARM for Thumb ISA). This can be a pain if your executable must load entirely into a tiny RAM dedicated to a core, as seen in the proverbial elevator controller [catb.org] , in multiplayer clients on the Game Boy Advance system (which run without a Game Pak present so they must fit into the 256 KiB RAM), or even in the Cell architecture (which gives 128 KiB to each DSP core).

Had a flashback there. (5, Funny)

palegray.net (1195047) | more than 5 years ago | (#27456111)

The story title conjured up images of the boxes of ISA cards I've still got sitting around. Ah, the joys of setting IRQs... good times.

Re:Had a flashback there. (2, Informative)

4181 (551316) | more than 5 years ago | (#27456547)

It's probably worth noting that although the actual article uses neither the acronym nor its expansion, ISA in the story title refers to Instruction Set Architecture [wikipedia.org] . (My first thoughts were of ISA [wikipedia.org] cards as well.)

Re:Had a flashback there. (2, Funny)

palegray.net (1195047) | more than 5 years ago | (#27456717)

Yeah, I just got weird mental images of ISA cards jutting out of modern-day motherboards. It was disturbing.

Re:Had a flashback there. (1)

fuzzyfuzzyfungus (1223518) | more than 5 years ago | (#27457621)

Didn't you hear? As of PCIE 3.1, compliant PCIE controllers will support detection, pin remapping, and an entire emulated 8086, allowing valuable legacy 8-bit ISA cards to remain in use!

Re:Had a flashback there. (1, Funny)

Anonymous Coward | more than 5 years ago | (#27457395)

So if this turns out to be good, will everyone jump on to the ISA bus?

Re:Had a flashback there. (0)

Anonymous Coward | more than 5 years ago | (#27457559)

I still remember the good old Sound Blaster 16

Port 220
IRQ 5
DMA 1
DMA(hi) 5

WTF. I do not want moar x86. (0)

MostAwesomeDude (980382) | more than 5 years ago | (#27456197)

Seriously, most of the Mesa shader assemblers deal with very limited, simple, straightforward shader ISAs. This is icky. We're gonna need a full-on compiler for this.

Re:WTF. I do not want moar x86. (3, Interesting)

joib (70841) | more than 5 years ago | (#27456441)

Isn't this exactly what Gallium3d + LLVM GLSL compiler is giving you? Heck, even with the simple shader ISA's you probably want an optimizing compiler anyway in order to get good GLSL performance, no?

Wouldn't this actually be a good thing; instead of spending all the time developing new drivers for each generation of hw (changing every 6 months, poorly if at all documented), you could just keep on developing the architecture and improve the x86 backend.

Re:WTF. I do not want moar x86. (0)

Anonymous Coward | more than 5 years ago | (#27457137)

Gallium3d interface/driver is only on Linux from what I understand so it's pretty useless for game developers that are trying to sell games.

Re:WTF. I do not want moar x86. (0)

palegray.net (1195047) | more than 5 years ago | (#27456443)

We need compilers that are far better at taking advantage of parallel architectures anyhow.

Re:WTF. I do not want moar x86. (1)

Cyberax (705495) | more than 5 years ago | (#27456451)

Will LLVM help with this? AFAIR, Gallium3D already supports rendering using Cell PPUs and Larrabee is going to look like them.

PS: thanks for your work on Gallium3D!

Re:WTF. I do not want moar x86. (1)

julesh (229690) | more than 5 years ago | (#27456745)

Seriously, most of the Mesa shader assemblers deal with very limited, simple, straightforward shader ISAs. This is icky. We're gonna need a full-on compiler for this

If you don't need the extra complexity of an x86 core, you can ignore it. Compilers for this system will be just as simple as compilers for current nvidia/ati designs.

Re:WTF. I do not want moar x86. (1)

makomk (752139) | more than 5 years ago | (#27456871)

I'm not convinced. It seems like Intel have just bolted a decent ISA for graphics work onto the side of x86. In typical graphics applications, I'm guessing the new graphics instructions will do most of the work - particularly for shaders. They seem fairly decent and sane, quite similar to other modern designs (though probably more flexible).

Now if you want real fun, try getting good performance out of r600 and up Radeon cards. Nasty VLIW architecture with all sorts of strange and interesting restrictions.

End of an era (2, Interesting)

pkv74 (1524279) | more than 5 years ago | (#27456199)

This 300 watts monter, 8086/386/586/x86-64/mmx+sse+ss2+ss3+whateversse compatible mess represents (or should represent) the end of an era. Few people is asking for that kind of product; price and size is more important. It's just Intel trying to hold the market captive forever.

Re:End of an era (2, Informative)

Repossessed (1117929) | more than 5 years ago | (#27456323)

Intel actually tried to build a different leaner, instruction set. IA64, the market rejected it.

Via and AMD don't have much trouble implementing these instruction sets either, or adding their own, so this doesn't much represent a stranglehold move on Intel's part.

If you really want cheap small processors with no extra instruction sets, Intel does still make Celerons, I dare you to run Vista on one.

Re:End of an era (3, Informative)

Hal_Porter (817932) | more than 5 years ago | (#27456387)

Actually the key patents on x86 probably run out soon. x64 has always been licensable from AMD. And an AMD or Intel x86/x64 chip has been at the top of the SpecInt benchmark for most of the last few years. Plus Itanium killed of most of the Risc architectures and x64 looks likely to kill off or nicheify Itanium.

Meanwhile NVidia are rumoured to be working on a Larrabee like chip of their own. Via have a ten year patent license, by which point the architecture is rather open. And Larrabee shows a chip with a lot of simple x86 cores is good enough at graphics for most people to not need a powerful GPU. I bet a Larrabee like CPU would be great in a server too, and it's trivially highly scalable by changing the number of cores.

I'd say x86/x64 will be around for a long time.

Re:End of an era (1, Interesting)

ThePhilips (752041) | more than 5 years ago | (#27456557)

Plus Itanium killed of most of the Risc architectures and x64 looks likely to kill off or nicheify Itanium.

This is misinformed B.S. Itanium didn't kill anything.

That was (and is) triumphant march of Linux/x64 all the time.

It is true that Intel and HP made out of PA-RISC and Alpha sacrificial lambs on Itanic's altar. Yet, Itanic's never caught up (and never will) to the levels where both PA-RISC and Alpha in the times were.

I bet a Larrabee like CPU would be great in a server too, and it's trivially highly scalable by changing the number of cores.

Servers are I/O heavy - CPU parallelism is very secondary. I doubt Larrabee would make any dent in server market. Unless of course OnLive/similar would catch up or Intel add something interesting for e.g. XML processing.

Re:End of an era (1)

julesh (229690) | more than 5 years ago | (#27456729)

Servers are I/O heavy - CPU parallelism is very secondary

I take it you've never tried to run a large-scale J2EE app.

Re:End of an era (1)

ThePhilips (752041) | more than 5 years ago | (#27456975)

With same success, I can run "for(;;;);" in several threads and run all CPUs/cores to ground.

No matter what Java folks try to make out of it, Java on servers is pretty niche - precisely because of inefficient use of resources.

Server Java is of course not so niche in whole Java market. But not other way around.

Re:End of an era (1)

binarylarry (1338699) | more than 5 years ago | (#27457643)

"Java on servers is pretty niche"

ROFL

Re:End of an era (4, Informative)

SpazmodeusG (1334705) | more than 5 years ago | (#27456593)

Look i hate to be anal, but neither Intel nor AMD have been at the top of the SpecInt benchmark for a long time.
The stock IBM Power6 5.0Ghz CPU is the fastest CPU on the specint benchmark on a per-core basis (and before that it was the 4.7Ghz model of the same CPU that was the leader).

http://www.spec.org/cpu2006/results/res2008q2/cpu2006-20080407-04057.html [spec.org]
Search for: IBM Power 595 (5.0 GHz, 1 core)
Which is telling considering it's made on a larger process than the fastest x86 (the i7). It really shows there's room for improvement if you ditch the x86 instruction set.

Re:End of an era (1)

Hal_Porter (817932) | more than 5 years ago | (#27456775)

Here are the SpecInt scores

http://www.onscale.de/specbrowser/2006-i.html [onscale.de]

The top score is an Intel Xeon X5570 at 2933Mhz
SPECint2006 = 36.3
SPECint_base2006 = 32.2

Look at SpecFP

http://www.onscale.de/specbrowser/2006-f.html [onscale.de]

The same chip is on top there too

SPECfp2006 = 42.0
SPECfp_base2006 = 39.3

Here are the results you linked to for a 5Ghz PPC were

SPECfp2006 = 24.9
SPECfp_base2006 = 20.1

So even at SpecFP where Risc has traditionally been quite a bit ahead, x86 is now on top. On SpecInt it's been like that for ages, at least since Athlon64.

Re:End of an era (3, Informative)

SpazmodeusG (1334705) | more than 5 years ago | (#27456809)

I said on a per-core basis!
The Xeon X5570 is a quad core machine!

Re:End of an era (2, Interesting)

sznupi (719324) | more than 5 years ago | (#27457163)

And what about per-Watt basis? (honest question here; though I do suspect i7 is quite a bit more competive here)

Re:End of an era (0)

Anonymous Coward | more than 5 years ago | (#27457333)

It doesn't matter unless you're looking at the SPEC rate scores, because only one core is used.

Re:End of an era (-1, Flamebait)

ZosX (517789) | more than 5 years ago | (#27457481)

It makes me wonder why Apple was so quick to ditch the Power architecture and jump ship to x86. Intel really needs something other than x86 to compete with on the desktop end. I understand that the Power road map was stated to lose competitiveness with intel's offerings and all, but given the fabrication shortcomings it still appears to be very much in the race. It would be terrible to rely on one single chip manufacturer and it makes me happy that there remains quite a few different architectures out there. The potential is there for us to be on the verge of a quantum shift in computing and yet we still cling to dinosaurs that still boot into standard real mode like its 1981 all over again. Its interesting to see how badly the sparc is flailing on specint. It makes me wonder what IBM will do with the architecture when they acquire it. There is still a big rift on the RISC vs CISC debate and if modern chip designs show any indication, RISC as a concept still won by a long shot as it sits at the core of modern x86 cpus today.

From the wikipedia:

RISC and x86

However, despite many successes, RISC has made few inroads into the desktop PC and commodity server markets, where Intel's x86 platform remains the dominant processor architecture (Intel is facing increased competition from AMD, but even AMD's processors implement the x86 platform, or a 64-bit superset known as x86-64). There are three main reasons for this.

      1. The very large base of proprietary PC applications are written for x86, whereas no RISC platform has a similar installed base, and this meant PC users were locked into the x86.
      2. Although RISC was indeed able to scale up in performance quite quickly and cheaply, Intel took advantage of its large market by spending vast amounts of money on processor development. Intel could spend many times as much as any RISC manufacturer on improving low level design and manufacturing. The same could not be said about smaller firms like Cyrix and NexGen, but they realized that they could apply pipelined design philosophies and practices to the x86-architecture -- either directly as in the 6x86 and MII series, or indirectly (via extra decoding stages) as in Nx586 and AMD K5.
      3. Later, more powerful processors such as Intel P6 and AMD K6 had similar RISC-like units that executed a stream of micro-operations generated from decoding stages that split most x86 instructions into several pieces. Today, these principles have been further refined and are used by modern x86 processors such as Intel Core 2 and AMD K8. The first available chip deploying such techniques was the NexGen Nx586, released in 1994 (while the AMD K5 was severely delayed and released in 1995).

While early RISC designs were significantly different than contemporary CISC designs, by 2000 the highest performing CPUs in the RISC line were almost indistinguishable from the highest performing CPUs in the CISC line.[10][11][12]

[edit] Diminishing benefits

Over time, improvements in chip fabrication techniques have improved performance exponentially, according to Moore's law, whereas architectural improvements have been comparatively small. Modern CISC implementations have adopted many of the performance improvements introduced by RISC, such as single-clock instructions. Compilers have also become more sophisticated, and are better able to exploit complex instructions on CISC architectures. The RISC-CISC distinction has blurred significantly in practice.

Re:End of an era (1)

the_humeister (922869) | more than 5 years ago | (#27457665)

Because there weren't any low-power 64-bit PowerPC processors at the time and Apple couldn't wait.

Re:End of an era (5, Insightful)

Anonymous Coward | more than 5 years ago | (#27456459)

IA64 was rejected because it was too lean. It's actually a horrendously complicated ISA which requires the compiler to do a lot of the work for it, but it turns out that compilers aren't very good at the sort of stuff the ISA requires (instruction reordering, branch prediction etc.) It also turned out that EPIC CPUs are very complex and power-hunger things, and IA32/x86-64 had easily caught up with and surpassed many of the so-called advantages that Intel had touted for IA64.

The only reason Itanium is still hanging around like a bad smell is because companies like HP were dumb enough to dump their own perfectly good RISC CPUs on a flimsy promise from Intel, and now they have no choice.

Re:End of an era (5, Funny)

Hurricane78 (562437) | more than 5 years ago | (#27456577)

So that is where the term "EPIC FAIL" comes from...

Re:End of an era (1)

ebuck (585470) | more than 5 years ago | (#27457629)

It's not that HP is dumb, it's greedy. HP owns something on the order of 50% of the IP that goes into an Itanium. If they can effectively block you from buying anything else, you buy into their patents. Intel is the other major patent holder.

Most of the patents for the Itanium are designed to make it impossible to produce an Itanium clone without violation the patents.

Re:End of an era (3, Informative)

turgid (580780) | more than 5 years ago | (#27456595)

Intel actually tried to build a different leaner, instruction set. IA64, the market rejected it.

It wasn't lean at all. It it typical over-complicated intel junk. Just look at the implementations: itanic. It's big, hot, expensive, slow...

If you really want cheap small processors with no extra instruction sets, Intel does still make Celerons, I dare you to run Vista on one.

The Celerons have all the same instructions as the equivalent "core" processors, they just have less cache usually.

This Larabee thing doesn't sound much different to what AMD (ATi) and nVidia already have. A friend of mine has done some CUDA programming and, form what he says, it sounds just the same. Just like a vector supercomputer from 10 years ago.

Re:End of an era (1)

Anonymous Coward | more than 5 years ago | (#27456657)

The difference is in threading: traditional GPUs are SIMD machines, which means that they handle lots of data at the same time but only perform a single operation on the entire data range. Recent incarnations support MIMD operations and conditional execution, but they still have single-threaded, single-context execution units.

If Intel really manages to build a multithreaded architecture with the same processing power as current (GP)GPUs, they might just succeed with their approach.

But to be honest, I'd much rather see any other company win this market segment, if only for the sake of competition. And of course, I want the x86 ISA to die. Having a 64-bit CPU still boot in 16-bit compatibility mode is just madness.

Re:End of an era (1, Insightful)

Rockoon (1252108) | more than 5 years ago | (#27456755)

Some people buy 300watt video cards..

..and some of them dont even do it for gaming, but instead for GPGPU

This is a real market, and as it matures the average joe will find that it offers things that they want as well.

The fact is that as long as even a small market exists, that market can expand under its own momentum to fill roles that cannot be anticipated.

I certainly wasn't thinking that there was a market for hardware accelerated graphics 20 years ago, yet I'm sure to make sure thats in the system I build today.

I certainly wasn't thinking about multi-core computers 20 years ago, yet I wouldn't buy anything less than a quad core today.

I certainly wasn't thinking about going from 20-bit to 32 -bit to 64-bit addressing 20 years ago.. I was happy with 640K and some bios above that, yet today if I build a system its going to have at least 8 gigs of memory.

I couldnt even dream of filling the 40meg hard drive I got with my first 386, yet now I am wondering if I should clean up my 500GB drive or simply buy a new 1TB drive to slot right next to it.

Yeah.. people weren't asking for those kinds of products either.. now we want them because those pesky unpredictable uses that come up that are actualy attractive to us.

Re:End of an era (1)

hairyfeet (841228) | more than 5 years ago | (#27456757)

If this thing really does need 300 watt [custompc.co.uk] just to power the card i predict it will go down in flames. The cards by Nvidia and AMD have made major strides on heat/power and Intel wants us to go back to 300 watt GPUs? WTF? I for one don't want or need another Intel space heater, thank you very much.

Not to mention this thing looks different enough from ATI/Nvidia cards that if it gains a foothold we could end up just like the bad old days of Win9x. In case any youngsters don't remember there was this little thing called Glide [wikipedia.org] which was a proprietary 3DFX tech that would only work on their cards, so you ended up with games that looked like shit if you didn't have a Voodoo card or games that supported the other cards but ran like shit on Voodoo. I personally like the fact that I can buy either Nvidia or ATI and have games both past and present work and have comparable graphics. This thing looks to be different enough that I'm betting code not written specifically for it will probably take a serious performance penalty. No thanks.

While I had hopes when it was first announced that Larrabee would be simply a new low power GPU by Intel that wouldn't suck, instead it looks to be another Netburst space heater. Meanwhile with the Ion and the 780 Nvidia and AMD have made great strides in the IGP space that currently is ruled by Intel. Between this and the way Intel seems to be burning their bridges with lawsuits from Nvidia and AMD one really has to wonder just what the hell they are thinking. Intel with their crazy maneuvers has made up my mind and for the first time since the old K2 I'm building an AMD box next month to replace my aging P4. Because with all this craziness who knows if an Intel box would support the GPUs that I want to run? Because just from what I have seen and read so far Larrabee simply isn't the GPU for me. So sorry Intel, but the insanity you have been pulling for the past few months have cost you this life long Intel man. Stick to the CPU and let companies with much more experience with graphics stick to the GPU.

Re:End of an era (2, Informative)

godefroi (52421) | more than 5 years ago | (#27457331)

Here's a little secret:

Lots of games (maybe all of them) already include graphics-vendor-specific rendering engines. It's just that nowadays your graphics API isn't your whole game development toolset (glide), so it's easy to include support for both (all) vendors.

Structural engineering welcomes this. (4, Interesting)

GreatBunzinni (642500) | more than 5 years ago | (#27456209)

As a structural engineering in training who is starting to cut his teeth in writing structural analysis software, these are truly interesting times in the personal computer world. Technologies like CUDA, OpenCL and maybe also Larrabee are making it possible to simply place in any engineer's desk a system capable of analysing complex structures practically instantaneously. Moreover, it will also push the boundaries of that sort of software beyond, making it possible to, for example, modeling composite materials such as reinforced concrete through the plastic limit, a task that involves simulating random cracks through a structure in order to get the value of the lowest supported load and that, with today's personal computers, takes hours just to run the test on a simple simply supported, single span beam.

So, to put this in perspective, this sort of technology will end up making it possible for construction projects to be both cheaper, safer and take less time to finish, all in exchange of a couple hundred dollars on hardware that a while back was intended for playing games. Good times.

Re:Structural engineering welcomes this. (0)

Anonymous Coward | more than 5 years ago | (#27456251)

Isn't the value of the lowest supported load zero? Why would it take hours to compute that?

Re:Structural engineering welcomes this. (2, Informative)

GreatBunzinni (642500) | more than 5 years ago | (#27456339)

When performing limit analysis, the lowest supported load calculated through the plastic limit (see limit analysis' upper bound theorem) is the lowest possible load that causes the structure to collapse. Then, if we compare it with the static limit of said structure (see limit analysis' lower bound theorem) we can pinpoint the exact resistance to failure of a structure and, from there, optimize it and make it safer. Which is a nice thing to do in terms of safety and cost.

Isn't that the "highest supported load"? (1)

tepples (727027) | more than 5 years ago | (#27456629)

When performing limit analysis, the lowest supported load calculated through the plastic limit (see limit analysis' upper bound theorem) is the lowest possible load that causes the structure to collapse.

I think Anonymous Coward was trying to say that the layman's term for this load amount is the "highest supported load" that doesn't cause collapse.

Re:Structural engineering welcomes this. (1, Insightful)

Anonymous Coward | more than 5 years ago | (#27456361)

"Math is hard" - Barbie

Re:Structural engineering welcomes this. (2, Insightful)

Anonymous Coward | more than 5 years ago | (#27456297)

As a seasoned structural engineer (and PhD in numerical analysis), I hate to say this, but this is partly wishful thinking. Even an infinitely powerful computer won't remove some of the fundamental mathematical problems in numerical simulations. I will not start a technical discussion here, but just take some time to learn about condition numbers, for instance. Or about the real quality of 3D plasticity models for concrete, and the incredibly difficult task of designing and driving experiments for measuring them. Etc.

Re:Structural engineering welcomes this. (1)

MichaelSmith (789609) | more than 5 years ago | (#27456381)

modeling composite materials such as reinforced concrete through the plastic limit

I wonder if that software could also improve animation, by making solid objects which look as if they actually have weight. Too many avatars seem to be hovering just above the ground because you don't see the forces being transmitted through their bodies.

Re:Structural engineering welcomes this. (2, Interesting)

Tenebrousedge (1226584) | more than 5 years ago | (#27456497)

That's a problem with the animator. You don't need complicated software to make good animation--Toy Story should be sufficient evidence of that. You just need talent. Less and less talent these days, actually: if you're playing a game where the avatars are floating, it's because the designers don't give a^H^H^H^H^H^H^H care enough to simulate motion properly.

As an aside, realism is frequently not a goal in animation. You tend to run up against the uncanny valley: all the characters look like zombies. Realism is what made "A Scanner Darkly" so painful to watch, especially as contrasted to "Waking life".

I think Larrabee has somewhat more potential to improve ray tracing. Lighting in games these days seems like layers of, well, kludges. The code works, and it's fast, but it's an ugly, ugly solution.

Re:Structural engineering welcomes this. (1)

Hurricane78 (562437) | more than 5 years ago | (#27456589)

Hey, "A Scanner Darkly" was not painful to watch. Not for anyone except you. ^^
I have seen it with many people, and most of them liked it. Some of them did find it a bit slow/boring. But nobody found it to be painful.

So if you always presume you are talking just about your views, then I apologize. But if not, please stop stop assuming everybody has your point of view. :)
Thank you. :)

Re:Structural engineering welcomes this. (0, Troll)

Tenebrousedge (1226584) | more than 5 years ago | (#27457075)

Your post is saccharine, condescending, vapid, and irrelevant to the subject at hand.

If you have an opinion on anything I was actually discussing, please share it. As an example, you could explore the visual differences between the two contrasted films, the science behind the 'uncanny valley, or perhaps discuss the merits of rotoscoping in general.

"I liked the movie. Some of my friends liked the movie."

The inanity is stupefying.

Re:Structural engineering welcomes this. (1)

m50d (797211) | more than 5 years ago | (#27457335)

It's condescending, and deservedly so, because you made an unsupported and likely false assertion. If you're going to claim something is "painful to watch", anyone interested in serious discussion should realise that's going to be contentious; you'd better give evidence to support it.

Re:Structural engineering welcomes this. (0)

Anonymous Coward | more than 5 years ago | (#27456669)

That's a different situation.

With an animation like 'toy story' they can tweak each pose till it looks right. And it only needs look right from one camera angle. There does not have to be any physics involved at all.

With a computer game, the poses have to be generated on the fly, and respond in real time to the environment.

Re:Structural engineering welcomes this. (0)

Anonymous Coward | more than 5 years ago | (#27456743)

Realism is what made "A Scanner Darkly" so painful to watch

Linlaker wasn't going for realism, the subject matter of the book and the fact he used rotoscoping should make that clear. The drug featured in the story is called "substance D" or "death" so your zombie analogy is quite accurate, although hardly an unintended side effect. The only thing that made Scanner Darkly a difficult film to watch was the hokey, bastardized ending.

With only a handful of exceptions, I see artifice increasingly taking the back seat whenever there's digital art involved in a production. I don't see Larrabee changing the "factory" mentality and I'm not in the slightest interested in the potential of Larrabee for graphics or audio. Fast ubiqutous crypto is the considerably more interesting use case -- a scramble suit for all.

Re:Structural engineering welcomes this. (1)

LingNoi (1066278) | more than 5 years ago | (#27457281)

You tend to run up against the uncanny valley:

I completely disagree that uncanny valley is a problem. It's simply not realistic enough and it's all down to the movement of said realistic character.

What are we? Meat bags. We're walking bags of water, yet when ultra realistic game characters are animated they're done so in a barbie dole fashion without taking into account the movement of mass on what they are simulating.

If game characters factored this in and did it right "uncanny valley" wouldn't exist, yet it does because game developers have failed to see why their game characters look unreal even though they're modelled perfectly and have given up.

Watch this [youtube.com] to get a better idea of what I am talking about.

Isn't it high time for a 80x86 cleanup? (0, Troll)

master_p (608214) | more than 5 years ago | (#27456225)

There are lots of instructions and other craft inside 80x86 processors that occupy silicon that is never used. A clean break from 80x86 is needed. Legacy 80x86 code can run perfectly in emulation (and need not be slow, using JIT techniques).

What I like most about Larrabee is the scatter-gather operations. One major problem in vectorized architectures is how to load the vectors with data coming from multiple sources. the Larrabee ISA solves this neatly by allowing vectors to be loaded from different sources in hardware and in parallel, thus making loading/storing vectors a very fast operation.

The programming languages that will benefit from Larrabee though will not be C/C++. It will be Fortran and the purely functional programming languages. Unless C/C++ has some extensions to deal with the pointer aliasing issue, that is.

Re:Isn't it high time for a 80x86 cleanup? (3, Insightful)

ShakaUVM (157947) | more than 5 years ago | (#27456351)

The programming languages that will benefit from Larrabee though will not be C/C++. It will be Fortran and the purely functional programming languages. Unless C/C++ has some extensions to deal with the pointer aliasing issue, that is.

Intel has a lot of smart people in their compilers group, and they've done stuff like this before in different times in the past. I wouldn't at all be surprised if they released compiler extensions to allow quick loading of data into the processing vectors.

Re:Isn't it high time for a 80x86 cleanup? (5, Informative)

joib (70841) | more than 5 years ago | (#27456489)

There are lots of instructions and other craft inside 80x86 processors that occupy silicon that is never used. A clean break from 80x86 is needed. Legacy 80x86 code can run perfectly in emulation (and need not be slow, using JIT techniques).

All the legacy junk takes up a pretty small fraction of the area. IIRC on a modern x86 CPU like Core2 or AMD Opteron, it's somewhere around 5%. Most of the core is functional units, register files, and OoO logic. For a simple in-order core like Larrabee the x86 penalty might be somewhat bigger, but OTOH Larrabee has a monster vector unit taking up space as well.

What I like most about Larrabee is the scatter-gather operations. One major problem in vectorized architectures is how to load the vectors with data coming from multiple sources. the Larrabee ISA solves this neatly by allowing vectors to be loaded from different sources in hardware and in parallel, thus making loading/storing vectors a very fast operation.

Yes, I agree. Scatter/gather is one of the main reason why vector supercomputers do very well on some applications. E.g. scatter/gather allows sparse matrix operations to be vectorized, and allows the CPU to keep a massive number of memory operations in flight at the same time, whereas sparse matrix ops tend to spend their time waiting on memory latency when you have just the usual scalar memory ops.

The programming languages that will benefit from Larrabee though will not be C/C++. It will be Fortran and the purely functional programming languages. Unless C/C++ has some extensions to deal with the pointer aliasing issue, that is.

There is the "restrict" keyword in C99 precisely for this reason. It's not in C++ but most compilers support it in one way or another (__restrict, #pragma noalias or whatever). That being said, I'd imagine something like OpenCL would be a more suitable language for programming Larrabee than either C, C++ or Fortran. Functional lnaguages are promising for this as you say, of course, but it remains to be seen if they manage to break out of their academic ivory towers this time around.

Re:Isn't it high time for a 80x86 cleanup? (4, Insightful)

serviscope_minor (664417) | more than 5 years ago | (#27456545)

The programming languages that will benefit from Larrabee though will not be C/C++.

Awwwww :-(

It will be Fortran and the purely functional programming languages. Unless C/C++ has some extensions to deal with the pointer aliasing issue, that is.

Oh. You mean like restrict which has been in the C standard for 10 years?

GCC supports it for C++ too. I'd be suprised if ICC and VS didn't support it for C++ too.

Re:Isn't it high time for a 80x86 cleanup? (1)

serviscope_minor (664417) | more than 5 years ago | (#27456631)

Seriously, can someone tell my mhy my post was a troll? The GP was rererring to the lack of a feature that C has had for 10 years. The C99 standard came out in 1999 and had the restrict keyword in it. This allows for optimizations on a par with FORTRAN since it provides the same guarantees.

I know it's fashionable to hate C++ and C overe here these days. Perhaps that's the problem.

Re:Isn't it high time for a 80x86 cleanup? (1)

ThePhilips (752041) | more than 5 years ago | (#27456639)

There are lots of instructions and other craft inside 80x86 processors that occupy silicon that is never used.

Rarely used instructions are not need to be optimized - then they would take very little of transistors to implement. Only heavily used instructions needs to be optimized.

The programming languages that will benefit from Larrabee though will not be C/C++. It will be Fortran and the purely functional programming languages.

I hope you do understand that Fortran was fast because programs written in it were also simple. Modern programs combine lots and lots of math, memory and I/O operations. You can't easily parallelize that. Even now it can be already perfectly parallelized in C/C++, yet resulting software is quite complicated to manage and maintain.

It sounds stupid, but Sun actually already optimized their Java's JIT for SPART T1/T2 which are highly multithreaded CPUs.

Re:Isn't it high time for a 80x86 cleanup? (1)

rcallan (1256716) | more than 5 years ago | (#27456647)


I think you're preaching to the choir here on killing x86. The x86 ops get translated to RISC ops anyway. What I wonder is why they haven't attempted to release two versions: an x86 version, and a stripped down RISC version without the x86 decoder. Obviously this would be monumental task at all levels of the design, but it would seem they could get similar performance on the RISC version without as much effort as needed for the x86 version since that overhead is removed. I would guess(and hope) that most of their design effort goes into optimizing the design in the RISC world after the instructions are translated anyway. This will never happen though because windows == x86 only. Being able to compile most of the needed applications from source gives hardware designers the freedom to shed legacy interfaces every 5 years instead of every 30. It would be a glorious future if hardware producers started realizing that open source software == greater hardware design flexibility == better performance/cost. Hopefully this is already happening with the shift from x86 to ARM on netbooks.

Re:Isn't it high time for a 80x86 cleanup? (2, Insightful)

gnasher719 (869701) | more than 5 years ago | (#27457127)

What I wonder is why they haven't attempted to release two versions: an x86 version, and a stripped down RISC version without the x86 decoder.

If you looked at what Intel has been doing recently, the RISC code that x86 is translated to has been slowly evolving. For example, sequences of compare + conditional branch become a single micro op. Instructions manipulating the stack are often combined or not executed at all. So what is the perfect RISC instruction set today isn't the perfect RISC instruction set tomorrow. And Intel's RISC instruction set would likely be quite different from AMD's.

Re:Isn't it high time for a 80x86 cleanup? (1)

makomk (752139) | more than 5 years ago | (#27456905)

According to TFA, the scatter/gather instructions are actually pseudo-instructions handled by the assembler on the current version of Larrabee.

If Intel are smart they will mix Core and Larabee (3, Insightful)

jonwil (467024) | more than 5 years ago | (#27456265)

If Intel are smart they will release a chip containing one core (or 2 cores) from some kind of lower-power Core design and a pile of Larabee cores on the one die along with a memory controler and some circuits to produce the actual video output to feed to the LCD controler, DVI/HDMI encoder, TV encoder or whatever. Then do a second chip containing a WiFi chip, audio, SATA and USB (and whatever else one needs in a chipset). Would make the PERFECT 2-chip solution for netbooks if combined with a good OpenGL stack running on the Larabee cores (which Intel are talking about already).

Such a 2-chip solution would also work for things like media set top boxes and PVRs (if combined with a Larabee solution for encoding and decoding MPEG video). PVRs would just need 1 or 2 of whatever is being used in the current crop of digital set top boxes to decode the video.

As for the comment that people will need to understand how to best program Larabee to get the most out of it, most of the time they will just be using a stack provided by Intel (e.g. an OpenGL stack or a MPEG decoding stack). Plus, its highly likely that compilers will start supporting Larabee (Intel's own compiler for one if nothing else).

Re:If Intel are smart they will mix Core and Larab (1)

SpazmodeusG (1334705) | more than 5 years ago | (#27456321)

I was thinking that. The Larrabees vector unit looks like it could just replace SSE entirely.

Which does raise a question - will Intel keep SSE if it adds in the Larrabee vector unit as yet another legacy feature? I'm guessing it will (sigh).

Re:If Intel are smart they will mix Core and Larab (1)

joib (70841) | more than 5 years ago | (#27456455)

Yeah, most x86_64 ABI's use SSE for scalar floating point, so it's too late to remove it. But hey, at least SSE is an improvement over x87.

Re:If Intel are smart they will mix Core and Larab (2, Insightful)

seeker_1us (1203072) | more than 5 years ago | (#27456427)

I don't think we will see this in notebooks for a while. We need to wait and see what the real product looks like (Intel hasn't released any specs), but Google for Larrabee and 300W and you will see the scuttlebut is that this chip will draw very large amounts of power.

Re:If Intel are smart they will mix Core and Larab (2, Interesting)

smallfries (601545) | more than 5 years ago | (#27457031)

Oddly enough your post ranks quite highly in that search. Drilling through the forums that show up reveal speculation that a 32-core Larrabee design will use 300W TDP, or roughly 10W per core. There doesn't seem to be any justification for that number although the Larrabee looks like Atom + stonking huge vector array. The Atom only uses 2W, it seems hard to believe that the 16-way vector array would use as much power for each FLOP as the entire Atom power budget to deliver that FLOP. Or perhaps it will, it's all just speculation at this point.

So that 32-core processor would deliver 16x32 = 512 FLOP/clock peak. I would guess that they could deliver a low-power part clocked at 1GHz judging by the efficiency of Intel's floating point units across the whole range (from Atom up to i7). That part would hit 512GFlop/s peak. Then it's just a guessing game of what clock-speed they could ramp it up to within that 300W TDP, 2Ghz? 3?

The real killer could be how much sustained throughput can be achieved on an x86 derivative. The Core-2 sustained throughputs were mental, but it used every OoO trick that Intel could throw at it. Without that advantage the peak:sustained ratio will be closer to AMD/Nvidia's current offerings.

Re:If Intel are smart they will mix Core and Larab (0, Flamebait)

smalfries (1524565) | more than 5 years ago | (#27457209)

To answer my own post, I'm not entirely sure about some of the facts. Like,... if I like the musty smell of men, does that mean I'm gay?

Re:If Intel are smart they will mix Core and Larab (0)

Anonymous Coward | more than 5 years ago | (#27456583)

A larger, more complex superscalar chip core + several smaller, simpler, and bus connected fixed-function units is also the exact design of the Sony CELL processor.

Not really x86 (0, Troll)

makomk (752139) | more than 5 years ago | (#27456363)

This isn't really x86, in my opinion; it's x86 with a separate set of very obviously graphics-oriented instructions bolted on top. Since getting decent performance will require using the new instructions and a new programming model almost exclusively, what's the point of the x86 bit? Well, other than marketing reasons and to prevent companies like NVidia releasing their own version, of course...

Re:Not really x86 (1)

Hal_Porter (817932) | more than 5 years ago | (#27456409)

I think the point is that in the long run you will have one Larrabee like chip in a desktop that does both the CPU and GPU functions. And in a server that same chip could manage a huge thread pool, which is the best way to do server applications IMO.

Re:Not really x86 (2, Insightful)

makomk (752139) | more than 5 years ago | (#27456525)

Perhaps. As it stands, though, I don't think Larrabee can run all standard x86 code, since it doesn't support legacy instructions. Plus, even if it did, the performance would suck. For desktop use, it probably makes more sense to have some real x86 cores and a bunch of simpler graphics cores that don't have to be x86. To get full benefit from Larrabee, the code has to be threaded anyhow, so there's not so much point being able to run it on the same core as the standard x86 code.

Re:Not really x86 (0)

Anonymous Coward | more than 5 years ago | (#27456467)

It's x86 because that's what Intel is already good at. Also, that's the whole point. Nvidia and ATI have vector processing chips, but that's all they're good for -- they're useless for general purpose programs because all they do is the vector part. Larrabee is great because it can run GP code as well as vector code.

dom

Re:Not really x86 (2, Interesting)

julesh (229690) | more than 5 years ago | (#27456947)

This isn't really x86, in my opinion; it's x86 with a separate set of very obviously graphics-oriented instructions bolted on top. Since getting decent performance will require using the new instructions and a new programming model almost exclusively, what's the point of the x86 bit?

The point is that there's stuff those graphics-oriented instructions are really not very good at, like indirect memory referencing and branching logic, both of which x86 excels at handling. Now, that kind of workload isn't common on GPUs _at the moment_, but both of those are common operations, for example, in ray tracing, so you may see them become more important over the next few years. What Intel are doing here is defining the GPU architecture for the next decade, and it's one that allows more complex algorithms to be implemented than can easily be done using the specialized stream processing systems we have at the moment.

The other point behind the x86 bit is that not only did Intel alrady have core designs that implemented it (Larrabee simply has the new registers & instructions bolted on to an existing low-power Pentium-class core) thus enabling faster time to market than if they'd developed entirely new hardware, they also have a massive amount of software support for the architecture, including one of the best optimizing C++ compilers there is. A new ISA would have required a new compiler, thus further complicating the project. As it is, only extensions to their existing compiler have been necessary.

SIMD... is it the right way to go? (1)

loubs001 (1126973) | more than 5 years ago | (#27456485)

Im skeptical about the future of SIMD and even instruction level parallelism in general for massively parallel processors. The problem with this is that in order to get maximum utiliasation of all of the ALUs in the processor, you have to fill the entire vector with data that you can perform the SAME operation on. This means its up to the programmer or compiler to write highly vectorizable code. If you cant fill these huge 512-bit vectors, arithmetic units are going to be idle. nvidia realised this years ago, and so since the G80 their architectures have been scalar. Without vectors you can run alot more scalar threads while keeping ALL the units busy all the time. Win Win. I'll need some serious convincing if I'm to believe Intel is a real threat to nvidia in this space, especially for GPGPU.

Re:SIMD... is it the right way to go? (2, Informative)

Anonymous Coward | more than 5 years ago | (#27456741)

nVidia G80 is scalar in the sense it's not VLIW (like ATI is), but it still has 32-wide SIMD. (Likely to go to 16 in next generations). 32*16 is actually 512 bits too.

Doing a truly scalar architecture would have an enormous cost in instruction caches - you'd need to move as many instructions as data around the chip, and that won't be cheap. So SIMD is going to be around for a while.

Nice try, more research next time.

Re:SIMD... is it the right way to go? (1)

makomk (752139) | more than 5 years ago | (#27456955)

Ding ding. Mod parent up. The real difference between current NVidia and ATI is that NVidia has sets of SIMD processors executing the same scalar operations on multiple pieces of data at once, whereas ATI has them executing the same VLIW instruction (up to 5 operations) on multiple pieces of data.

As I recall, ATI's SIMD cores work on 16 pieces of data at once (16 pixels, for example) whereas the internet information suggests that NVidia's work on 32.

Larrabee really isn't that revolutionary, by the way; it's more a generalisation of what other graphics cards already do.

Re:SIMD... is it the right way to go? (0)

Anonymous Coward | more than 5 years ago | (#27456753)

n order to get maximum utiliasation of all of the ALUs in the processor, you have to fill the entire vector with data that you can perform the SAME operation on

That's what is bothering me too, since I did not notice any explicit memory hierarchy, just a bunch of caches. It seems this incarnation of Larrabee could be quite latency sensitive.

"GPU class rendering in software" (1)

serviscope_minor (664417) | more than 5 years ago | (#27456521)

The claim that this is the first time you can get "GPU class rendering in software"... with nothing more than a pixel sampler to help is somewhat dubious. Modern GPUs are, after all a bunch of stream processors with a pixel sampler. So, really, modern GPU graphics is all in software except the sampling.

Oh, hey and anyone here remember the voodoo? That was a big (for the sime) sampler driven by an x86 CPU. Sound familiar?

Sarcasm aside, I want one. The peak performance is high, and the programming model is well known. Also, Linux support is likely to be excellent.

Re:"GPU class rendering in software" (1)

tepples (727027) | more than 5 years ago | (#27456643)

The claim that this is the first time you can get "GPU class rendering in software"... with nothing more than a pixel sampler to help is somewhat dubious. Modern GPUs are, after all a bunch of stream processors with a pixel sampler. So, really, modern GPU graphics is all in software except the sampling.

As I understand it, the key difference that makes the software running on Larrabee more like traditional "software" than NV's or ATI's offerings is that Intel is exposing these stream processors' instruction sets to let compiler writers compete on writing shader compilers.

Re:"GPU class rendering in software" (0)

Anonymous Coward | more than 5 years ago | (#27456785)

ATI has been exposing their instruction set to everyone since R600 (it's somewhere on x.org website even). Nobody ever cared.

You got suckered :-) (oh, pardon, 'marketed to').

Re:"GPU class rendering in software" (1)

tepples (727027) | more than 5 years ago | (#27456973)

ATI has been exposing their instruction set to everyone since R600

In that case, "software" might refer to Larrabee's use of an ISA so closely related to one that has already had plenty of research into optimization. Or it could mean an ISA that isn't so limited to the kind of processing that occurs in the sorts of vertex and pixel shaders that we have seen up until now.

Transcendental functions? (2, Interesting)

julesh (229690) | more than 5 years ago | (#27456553)

Articles states that there's hardware support for transcendental functions, but the list of instructions doesn't include any. Anyone know what is/isn't supported in this line?

Re:Transcendental functions? (4, Informative)

gnasher719 (869701) | more than 5 years ago | (#27457073)

Articles states that there's hardware support for transcendental functions, but the list of instructions doesn't include any. Anyone know what is/isn't supported in this line?

"Hardware support" doesn't mean "fully implemented in hardware".

What hardware support do you need for transcendental functions?
1. Bit fiddling operations to extract exponents from floating point numbers. Check. 2. Fused multiply-add for fast polynomial evaluation. Check. 3. Scatter/gather operations to use coefficients of different polynomials depending on the range of the operand. Check.

Excuse the Serenity reference... (5, Funny)

chrysrobyn (106763) | more than 5 years ago | (#27457033)

Article: "Things are going to get interesting."

nVidia: "Define interesting."

AMD: "Oh God, oh God, we're all gonna die?"

Fuck Parralization (0)

Anonymous Coward | more than 5 years ago | (#27457077)

That's why you buy... 2 COMPUTERS! Where's the single string performance! Fuck more! Smaller, faster, Intel get on it!

isa (1)

saiha (665337) | more than 5 years ago | (#27457113)

wtf does the international school of amsterdam have to do with this?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>