Slashdot Mirror

Actually, those rates sound high to me. The last two conferences I attended (this and this) industrial members didn't have to pay more than $400 if they registered early. Snacks & coffee were always available, and a few meals and drinks (yes, I'm still a grad student these things are important to me :) And all the proceedings are free to access online.

Maybe some of the money goes towards scholarships, but I doubt that all of it does. Anyway as a student it works well for me, I don't want to pay towards other students' fellowships, I'm not going to buy the IEEE dental insurance or whatever, and I don't need a glossy magazine in my department mailbox. Maybe that stuff would be more important if I were in a sexier field? I dunno.

There is only so much spectrum. Either force everyone to N-only or tell them the WiFi might not support everyone. You can only use channels 1, 6 and 11 in 2.4GHz due to overlap of the other frequencies. Look at figure 10 in this paper that studied throughput vs. channel overlap.

Software translation has serious problems. Fetching code and executing it in hardware will always be more efficient than running it through a translator, because the translation code itself takes up space in the cache, execution time and memory bandwidth.

If the Risc chip were faster than a comparable x86 it might be tolerable, but this Risc chip isn't. It's comparable to a R16000, a 2002 vintage superscalar MIPS processor. Intel and AMD chips have six years of microarchitectural innovation and are built on better fab plants.

What's interesting about it is that modern x86 chips actually don't execute x86 instructions in their pipelines, they have a hardware decode unit which transforms x86 to some internal format, probably Risc or VLIW. In fact this is what killed Risc. This use of 'decoupled architectures' in x86 is really what killed Risc.

Initially the cost of the hardware decode unit was rather steep

E.g.
http://studies.ac.upc.edu/ETSETB/SEGPAR/microprocessors/pentium2%20(mpr).pdf

The P6â(TM)s CISC handicap shows in two places. Despite the similar microarchitectures, the P6 requires nearly twice as many logic transistors as the MIPS chip; the extra logic handles x86 decode, uop translation, and the foibles of the x86 instruction set. Since both chips have similar die size and transistor budgets, the R10000 is able to include four times as much on-chip cache as the P6, improving performance on many programs. Second, the first P6 will run at 133 MHz, while the R10000 is expected to achieve 200 MHz using a similar manufacturing process. To come even this close in clock speed, Intel uses a very deep pipeline, a concept that MIPS tried and rejected for the R10000. The deeper pipeline has greater branch penalties, sapping performance.
And, of course, the higher clock speed gives the R10000 an intrinsic performance advantage. As a result, the MIPS chip should achieve at least 50% better integer performance than the P6.

At this point, decoupled x86 needed twice as many transistors for the core excluding caches because of the hardware decode. It also ran at a slower clock rate.

But in a modern x86 like Core2 the extra decoding compared to Risc is actually quite a small percentage of the total die size and therefore chip cost. Intel have done very well with clock speed too, outpacing Risc chips.

I suspect that Risc was good initially because you could execute instructions with a small and therefore fast block of logic because the instructions were very well matched to the pipeline. MIPS after all stood for "Microprocessor without interlocked pipeline stages". Branch delays, exposed to the programmer, were a natural consequence of the way the pipeline worked. But later superscalarar, out of order chips with register renaming are much less well suited to classic Risc instruction sets. E.g. a once cycle branch delay is not natural in a two way superscalar chip. Register renaming and out of order execution require loads of hardware whether you have a Risc chip or a Cisc one.

So back when Intel convinced Compaq that switching to Mips processors was a bad idea, it turns out they were right.

I know typing this out will be useless, and it will get overlooked by the mods, but I might as well say this. Asynchronous designs have several advantages :

1. It will give good power consumption characteristics i.e. low power consumed, not just because of the built in power down mode, but also because of the voltage the chips will be running at. By pulling the voltage lower than a synchronous equivalent, it will be simpler to have greater power savings. This becomes possible if you are willing to sacrifice speed. and in async devices, speed of switching can be dynamically altered as each block will wait till the previous one is done, not until some outside clock has ticked.

2. Security: Async designs give security against side channel power analysis attacks. As all gates must switch (standard async design usually uses a dual rail design, so most gates means all gates along both +ve & -ve switch), differential power attacks become much harder. Thus async designs are perfect for crypto chips (hardware AES anyone?)

3. elegance of solution:the world is generally async. Key presses are, memory accesses are. so why not the processor :). (Yes I know busses are clocked, before you start, but if they were not.... )

But they have several points of disadvantage:

1. They are hard to do. Especially using the synchronous design flow that most of the world uses. Synchronous tools assume, especially in RTL, that the world is combinational, and that sequential bits are simply registers that occur once a clock cycle (not true for full custom designs like intel and amd, but for slightly lower level : esp ASIC design)

2. The tools that exist now, are either able to do good implementation using only a few gates ie small functions or bad implementations, that are in worst case as slow as synchronous equivalents but are larger functions. Tools exist like http://www.lsi.upc.edu/~jordicf/petrify/ Petrify , but these become unusable for circuits with more than ~50 gates.

3. Async designs are usually large. This is not always true, but standard async designs are usually implemented as dual rail or using 1-of-M encoding on the wires. But the main overhead comes from the handshaking circuitry. For really fine grain pipeling, the output of each stage must be acknowledged to the previous stage. This adds a massive overhead, as it necessitates the use of a device called the Muller C Element, that sets the output to the output, only if the inputs are the same, or retains the previous value, if not. Many copies of this element are usually required, and its this that adds space, for example, a simple 1 bit OR gate, that would usually have 4 transistors, has 16 transistors for the dual rail async implementation.

For the time being, I think they will find a lot of use in low power applications - such as embedded microcontrollers/processors, in things like wireless sesnor networks, and security processors. However I believe that full processor design is very far off.

I studied the alpha prior to the announcement that their new version would have out-of-order, so I don't know if they ever did go that route.

Yep, with the 21264 - aggresively out-of-order CPU. The 21064 and 21164 might not have executed instructions out-of-order, however they were highly speculative. AXP arch was designed for out-of-order from the beginning, the two early CPUs did memory IO out-of-order. 21064 had a 32 entry register file it seems, not 2, btw, according to a paperp on the AXP 21064 I found on google written by a DECy.

Their performance would be comparable to the AMD-64, but not much faster.

Agreed, cause guess what: AMD64 is Alpha's progeny-in-spirit. ;)

The AMD K7 is very alpha-like (hence so is the K8). Highly speculative, out-of-order, wide multiple issue CPUs like the 21264. Not co-incidentally given that Dirk Meyer, co-architect of the 21264, led the AMD K7 design team. K7 used the 21164/21264 EV6 PtP interconnect too. K8 made it routable with HyperTransport - just as DEC^WCompaq did with EV6 in the 21364. You would still expect this mythical equivalently developed Alpha to beat AMD64 though, given it'd be able to use the die-space 'wasted' on x86-decoding for something more productive (cache or somesuch).

Native code is faster than emulated code!

Funnily enough, not always. Scroll about halfway down and look at the benchmarks. Bear in mind that this paper is about running native code through a JIT compiler-like system and comparing that with running the exact same native code directly on the OS.