Yes, each core has a local subset of L2 cache memory, which I assume it can access at full speed. The 1024 bit ring bus connects the L2 subsets, texture samplers, and memory interface.I don't think they can. 1024 bits divided between a maximum of 16 cores would leave only 64 bits per core per cycle. That's only 2 Zs per core, so 1/8th of the full vector width. Maybe the next incarnation of Larrabee will be different, but this was what was discussed previously.
Edit: I think I see what you mean now. You're implying that each vector unit can use its local memory to write out 16-wide vectors per clock. That would be 256 Zs per clock, assuming nothing else interfered.
I mean, you start with C code or something equivalent, it gets compiled to x86 code, it gets decompiled into the original C operations, you perform whatever optimization applies to your processor, and output RISC code.
A minor nitpick is that Transmeta's design was VLIW.But why? If RISC is so superior why not translate it into a sequence of superior RISC instructions?
Efficeon topped out at 7 watts and was about 68mm2, with 1 MiB L2 cache, on-die memory controller, and HT link.Atom is also a significantly smaller chip with reduced power consumption.
Pentium was of an earlier age, and an earlier Alpha beat it by 1/3 in size, with better integer and FP performance.That's indeed likely. The transistor density difference might be due to the dynamic logic versus CMOS. Either way it's hard to conclude that the Pentium was inferior due to x86.
I'm curious about that. Do you have some extensive benchmark results comparing Atom and an ARM processor? I'm not implying that Atom would beat ARM at any metric, but I wonder how big the difference really is, and how that would impact something like Larrabee.Really? Tell me that when you see atom beating arm at perf/mm/W. Come to think of it, we'll see how much ISA matters when ARM cortex A9 faces off with intel atom next year.
Sure, but at least Intel didn't blow off that launch (yet) so it must (still) be confident that the hardware is competitive. Even if it doesn't make a big impression, it seems to imply that the hardware is less off-course than the software that would turn it into a GPU.LRB's readiness for the HPC market is a matter of speculation at the moment.
The fact that it supports full cache coherence is not an invitation to go and trash the caches of neighboring cores. It's the software's responsibility to keep a high locality of reference. However, coherency is there to make the developer's life easier for when data does have to implicitely cross from one core to another, or when threads occasionally migrate to another core. It also again means that it's straightforward to get a prototype running, and only later worry about performance, where it matters.x86 might make sense for intel from a time-to-market pov. But it is clearly a luxury to developers in the near term, and it is not at all obvious if lrb can afford it. Also full cache coherency in hw is of limited utility when you have O(100) hw threads. Shared mutable state is a bane of parallel computing, then why should there be support for it in hw.
On the sw development (by external devs) side, most of the code you speak of will need a recompile. And you never know when simple recompiles make porting tricky. My knowledge of CISC vs RISC wars is limited, but if recompiles were so simple, I imagine RISC vendors would not have had so much of a lack-of-sw problem.
Why? There are x86 decompilers that reconstruct the C code perfectly (except formatting of course). They had every bit of opportunity to run this faster on a VLIW processor.
You mean to perform additional optimizations not performed on the x86 code? I'm sure Transmeta was able to run unoptimized x86 code faster than an x86 processor. Big deal. The real challenge is to run optimized x86 code faster. When that fails, let's blame the recompiler for not optimizing things the x86 compiler didn't spot either?
It makes no real difference. With or without source code you could rewrite x86 assembly for any other ISA and the number of operations (not instructions) and their dependencies remain the same.
i really don't understand your logic about ISA acceptance - ISA's today are mostly judged by how well they play with their compilers (from coders' perspective), and meet their price/performance/wattage envelopes (from EE/business perspectives) - not by their proximity to their 40th anniversaries. look round you - chances are you'll find more devices hosting 'young' ISAs than such hosting x86 or older. so what reception and by whom are you concerned about?
amazing what a paramount difference a decade (mid-70s to mid-80s) can do for cpu designs, eh?Doubtful. The two most popular ISAs in the world were both designed/developed in the early 80s. Collectively they make up more than 50% of all processors sold each year.
I'm curious about that. Do you have some extensive benchmark results comparing Atom and an ARM processor? I'm not implying that Atom would beat ARM at any metric, but I wonder how big the difference really is, and how that would impact something like Larrabee.
Fine. But incremental costs involved in changing your code to stick to 192K data per core is going to be large as well, even if you have the benefit of getting the full code running at horrible speeds at the beginning. (It'll prolly end up as a full rewrite.)The fact that it supports full cache coherence is not an invitation to go and trash the caches of neighboring cores. It's the software's responsibility to keep a high locality of reference. However, coherency is there to make the developer's life easier for when data does have to implicitely cross from one core to another, or when threads occasionally migrate to another core. It also again means that it's straightforward to get a prototype running, and only later worry about performance, where it matters.
Not additional optimizations, just different optimization decisions. I'm thinking things like making different inlining decisions based on better knowledge of the code size/run-time of small functions and available register space. It's also not at all clear to me that things like loop unrolling decisions would be identical between architectures. Also, replacing trig functions and other compiler built-ins with instruction sequences specifically optimized for the target ISA might provide some benefit...
amazing what a paramount difference a decade (mid-70s to mid-80s) can do for cpu designs, eh?
also, i would not call ARM as found today (mainly in the forms of v4 & v5, less so in v6 - the ISA iterations that power the consumer-segment telecom industries (cell phones, home routers, etc)) a superset of v2 - in contrast to intel, ARM actually deprecate elements of their ISA. they also add totally optional extensions (in their reserved 'extension spaces' - i wonder when intel will invent that), which makes the ARM ISA a living, mutable beast.
I'm getting 24.3 Mtris/s here. During this test only 20% of time is spent in primitive setup and rasterization. Scatter/gather support and other LRBni features would also help tremendously.With 3dmark2001 I'm getting 8 Mtris/s
I'm getting 24.3 Mtris/s here. During this test only 20% of time is spent in primitive setup and rasterization. Scatter/gather support and other LRBni features would also help tremendously.
easy there cowboy, the idea i was trying to convey was that of the extensions being optional* (though i did word it poorly, perhaps with the wrong brackets, but you still don't have to assume the other party are idiots who haven't seen the opcode space of the dominant desktop ISA). point is, ARM's extension spaces are actually optional - and not for architecture licensees only, but for ARM themselves - you could have a contemporary ARM design with arbitrary extensions omitted, based on the targeted market**. intel's x86 extensions, just like their whole holy cow of an ISA, are an example of the opposite - deep entrenchment. IA32's whole philosophy is pretty much that of the tarball - everything it touches gets stuck on it indefinitely (because, gasp, once an opcode gets into windows there's no turning back!). of course, feel free to disprove that and quote the number of intel x86 designs released after the p3 era (or even at the era's end, if you like) that don't feature SSE, for instance. once you do that, you can repeat the same with the number of intel's x86 opcodes that have been deprecated (by intel themselves, of course) for a stronger impact. and you surely must be aware how this always-accumulate-never-reduce approach affects the decoding logic (how many escape codes are intel up to these days in x86?)You mean like SSE/MMX/ETC? You obviously have no idea what you are talking about. Please do some research.