Reed-Solomon can correct bit errors, Turbo Codes can correct block errors, and if you also include a cryptographic hash of the packet you can determine if the corrections fixed the data or it is still corrupt. Depending on the bandwidth consumed by the actual data, you might be able to throw in a lot of error correction bits and even have the error correction checksummed and error-corrected.
The SPARC is crappy at floating-point and Oracle probably want to kill it anyway. I also can't afford a FPGA that'll take the entire open-sourced T2 code. Damn.
Sure you can - provided the problem can be divided amongst nodes efficiently (the communication is slower over clusters, so the more communication you need, the more tightly integrated you need the system). Oh, and provided you have space. Clusters don't scale linearly, so to get the same performance as a single CPU that can do four times as much (larger registers and more of them), you need more than four times as many CPUs. See Amdahl's Law for details.
Oh, and each node on the cluster needs its own OS, so instead of running one Linux kernel over a multi-core multi-way motherboard, you're now running multiple Linux kernels. Each one takes CPU and memory resources, so to get the same available CPU power you have to have extra nodes to cover the overhead.
I don't know why the fascination with GPUs - they're faster than CPUs for most maths problems, sure, but if you took just the maths portion and replaced the rendering portion with common maths primitives (bits of the BLAS library and maybe a chunk of FFTW) reimplemented in hardware, you'd have something that was SO much faster than any GPU. GPUs are only useful because they're there now and a proper maths co-processor isn't. I see no reason to be a slave to an inferior solution when a superior one could be built in short order whenever the chip manufacturers bother.
(And it is a case of them bothering. They've made maths co-processors before, it's no big deal, and SystemC makes it relatively easy to produce a first pass at hardware from a software description. The number of consumers who would buy a maths co-processor is limited and obviously only scientific software that uses the software libraries currently would be trivial to adapt to hardware implementations, so there's bugger all market incentive for them to bother, and that is ultimately why no such cores exist. There aren't enough scientific software users to justify the R&D or the production of a specialized processor, but there ARE enough gamers to justify building faster GPUs and so the technical community gets to use sub-optimal crap as a result.)
Which, IMHO, is utterly wrong, completely in violation of the spirit of what a trademark is and probably in technical violation of the written law but IANAL.
The first two books were good, I found the third one to be a big let-down and suspect that she was pressured into writing excessive sequels to series she wanted closed.
She was still posting on her blog and replying to fans a few weeks ago. I think it is her relationship with the fans that kept her going, to be honest. I met her at WorldCon in Glasgow back in the 90s and she wasn't all that well then. But when she talked with those of us at the coffee clatch, her energy seemed boundless.
Doesn't matter if the chess program can look at a million more moves or a billion. Chess Grand Masters look at patterns and compute which patterns are better than other patterns, which means that the pattern itself is a function. The better the Grand Master, the better the evaluation function. You need only have a function that evaluates the permutation of pieces on the board to a degree that is greater than the computer's evaluation of the permutation of a billion moves. Since Chess is a Full Information Game, it is provable that, for one of the sides, an evaluation exists such that looking a single move ahead will guarantee a win or a draw against any defense and that the other side can always force a draw if a single error is made.
So, yes, it is because you're lazy. Have you tried to produce a superior evaluation method? Have you really analyzed the maths? No? Then you haven't applied the effort needed. It is not the computer that has won, it is you who has lost.
20 chefs? Critical Path Analysis will show you every single scheduling conflict, when it will occur, where it will occur and how it will occur. You can timetable everything to that, with the breaks needed to synchronize neatly plotted out for you. 20 threads on a CPA is trivial. A major project might easily have a hundred. A parallel execution plan? Why? CPA will tell you the scheduling. Ok, how to divide resources? Well, it's a linear problem, so Operational Research would work fine. You want to recombine the elements to be efficient and the tools for that exist and taught to first years.
It IS still just recipes, but if N recipes call for egg yolks to be mixed well, you might as well have one chef mixing all that the recipes require then dividing up the mix into the right proportions and not have 20 chefs doing exactly the same thing. It's not hard. You make it complicated by believing it's complicated. It isn't. What is complicated is changing your mindset from serialized Mrs Beaton cookery to parallelized cooking of the kind that was actually commonplace in early cultures. (There was a fascinating find recently in Mesoamerica of gigantic cookware used to prepare dishes using this form of parallelism.)
There may well be Maoris on Slashdot. You can't see tattoos over the Internet. Now, there are probably no Moa on Slashdot and I hope there are no Keas (they're terrorists, I tell you!), but that's ok, there are enough bird-brains as it is. I have great respect for the Maori and it is intensely sad that I lost all of my mementos from my year in New Zealand after a storage place fire.
Back to the issue at hand. It is completely reprehensible that a "common word" (because it IS a common word in New Zealand) can be trademarked at all. That is not acceptable, in and of itself. It is a flagrant abuse of the system, relying on the fact that Americans are not very up on foreign cultures. I am increasingly of the opinion that words should not be trademarkable at all. A "trademark" is, after all, first and foremost a mark. From the Sumerians to the Victorian English, this has been a stamp, a unique symbol that denotes the origin and guarantees authenticity. Arguably, the seals produced by stamps and signet rings serve the same function.
You can always make a new symbol. Creativity is endless. But you can't create a new language every time foreigners decide to trademark words from it.
Well, the Itanium version 3 isn't too bad on performance. I agree it devours watts the way... well, nothing quite consumes anything the way the Itanium soaks up watts. That is a major flaw. The clock speed is an interesting one - I'll accept it can't ramp the way Intel expected but certainly overclockers have brought the 5 GHz processors up to 7 GHz without losing stability. It just can't be done at current temperatures. That means they either need to switch entirely off air-cooled chips or they need to make a radical chip change.
The radical chip change isn't unreasonable. Adding insulation layers, stressing the silicon, switching to copper interconnects - these all allowed clock speeds to grow. Copper, however, isn't the best conductor - silver is. The problem there is that silver is a bastard to work with - the chemistry isn't as friendly and it's extremely soft. The heat transfer off the silicon to the heatsink is also not great - I'd have thought flooding the inside of the chip with Fluorinert and replacing the top part of the chip casing with something highly conductive might be a better option since you'd get better heat transfer than with an air gap and plastic. Much more expensive in materials and much more complex manufacture, so vastly reduced profit margin, but it should boost performance.
(The other choice - naked silicon - would lose heat the best but it's much much harder to get that right in a liquid cooled environment. It is done, but I'd challenge anyone to find a person crazy enough to build a robust machine that way any more.)
Then there's asynchronous designs. The AMULET series of processors are asynchronous SPARC processors, so you can build general-purpose CPUs of moderate complexity that are actually useful this way. It has not been proven that you could build a modern superscalar 64-bit CPU of equal or greater performance to modern synchronous processors using the asynchronous tools that exist. (If you want, you can try them. They're open source and listed on Freshmeat - sorry, Freecode.) It may solve the roadblock, so far it hasn't.
Sensitivity to signals and electron tunneling are other obstacles to increasing speed. Of course, there's nothing to say you HAVE to use electrons. There are optical switches today and it's commonplace to build transceivers into silicon these days. You'd need to go 3D on the design to fit everything in and have line-of-sight, but it could be done.
Wikipedia also states "The term VLIW, and the concept of VLIW architecture itself, were invented by Josh Fisher in his research group at Yale University in the early 1980s". So it's an idea that's older than any of Intel's development in the field. It's a simple evolutionary step from horizontal microcode, since the whole idea is to have instruction-level parallelism. The disadvantage of CISC over RISC is that RISC turns out to be much faster. However, most chips these days are hybrids of RISC and CISC, thus minimizing bus activity and maximizing processor utility. A sensible approach to VLIW is to also hybridize. VLIW is designed to permit instruction-level optimizing that is impossible with CISC by passing additional specific information. There's absolutely no need for the processor to actually process a VLIW instruction directly, since we know RISC is superior. Instead, reduce the RISC set further, to more elementary compute elements, and have the VLIW decompose to it.
That's one reason that the Itanium sparked a massive revolution in source-to-source compilation. These meta-compilers turned things like C code for the GCC into something that was (a) optimized and (b) often for another compiler.
Intel has not done itself any favours with the Itanium - if it truly wanted an upsurge in usage, they'd collaborate with something like Google's Summer of Code, hand out a number of free Itanium developer boards to students and open-source developers, and get a massive surge in development that way. Ten Itanium developer boards would be pocket money for Intel in comparison to the cost of the division they're running for the processor, but ten Itanium developers over 3 months could make serious inroads into eliminating defective GCC optimization assumptions.
It's ironic that GCC still has such defects, given that PGCC - the Intel branch of GCC - was rejected by the EGCS developers because it made defective optimization assumptions. Platform-specific assumptions may be valid but should be in the platform-specific portions of the back-end and pre-optimizations that conflict with the platform should be masked out. If multiple implementations of a platform differ in platform-specific optimizations, detect or flag and then use the correct specifics. If the current GCC developers aren't willing to pay attention to this portion of compiling, then maybe we need another EGCS-style takeover bid.
(In fact, most processor manufacturers might want to chip in together to get GCC optimization straightened out. It's a valuable compiler to get right since open source won't go away and it's less of a PR disaster if experiments in GCC end up flopping than experiments in commercial compilers.)
All designs have limitations. Nor would I claim that the Itanium is the greatest processor out there. It has some great ideas, the second iteration was actually a decent invention, and it shows some nice creative elements. The flaws in the concept could only be revealed by actually implementing it and - as Linux kernel developers keep pointing out - actually putting it out there to test. Developers can't put anything, hardware or software, through all the real-world experiences, only users can do that and despite the wide availability of test silicon or test kernel releases, users won't test until it's mainstream.
The legacy limitations of the x86 are a major hindrance to development. (Back when the 68040 was commonplace, you'd never have seen this kind of fanboi reaction to me disliking the x86. People saw the alternatives, used the alternative and loved the alternatives. It's only modern users who have no experience with the true power of real designs that you see this kind of clingy addiction to arcane and archaic legacy defects.)
I've programmed the StrongARM, the MIPS64, the UltraSPARC, the M68040, the T800 Transputer, the DEC Alpha and every 80x86 processor save the Crusoe at the instruction level. Oh, and most of the 80x87s as well, except for IIT's 80x87 which I'd have loved to use as it could process entire arrays in single instructions. I know the alternatives. I've used processors that have no registers at all, just a bank of on-board RAM that you could divide and use as you wished. I've seen stuff in processor designs that are beyond the comprehension of those who have never seen outside the PC world. All of these processors had flaws and some died because those flaws were retained for compatibility purposes. But nobody who has that kind of breadth of experience believes that the flaws you know are worth clinging to. It's better to strike out boldly and risk failing than to tepidly patch. Evolution always dead-ends, but revolution can continue indefinitely.
I dislike stagnation of any kind. Learn, grow, incorporate, then invent. That is the only long-term solution. That's as true of bus technology as CPU design. If I were to design a bus, I'd look at the lessons learned from VXI, HyperTransport 3.1 and PCI Express 3, I'd want to know what worked and what didn't, but I wouldn't clone any of them. What would be the point? You can't invent if you don't know why things work the way they do, but you should never re-invent the wheel. If it's worth inventing, it's worth inventing something the wheel can never be.
Sure you could have off-processor caches on the 4004. Nothing stopped you. The first off-processor caches in mainstream use were for the 8086 and they became commonplace with the 80186.
No, I do not regard the modern x86 as requiring engineering. What Seymour Cray did (design each new computer one transistor at a time) was engineering. The x86 architecture is mere evolution, a catalogue of stepwise refinements on an existing design. There has been no truly new x86 design beyond the first. Everything since then has merely taken some component that already existed and improved it. Engineering is holistic, not piecemeal. Engineering is also not backwards-compatible, but it is backwards-compatibility that makes the x86 as useful as it is. Engineering is about solving the problems in front of you, not emulating the solutions imagined to be best for problems that no longer apply. Engineering is inventive, creative and novel. It's fresh.
The x86 is none of these. It is a piece of superb craftsmanship, old skills honed by years of use and experience. It takes a craft master to put a modern x86 with all the components necessary into hardware. But a craftsman is not an engineer. A craftsman is an expert rooted in PAST experience and PAST knowledge, building on those and relying entirely on them as foundations for improvement.
An engineer is a scientist, not a craftsman. Engineers do not look at the past for guidance, they look at the future for opportunities. Craftsmen can produce reliable work but they cannot produce truly new work, it takes an inventive mind to do that and crafters are the absolute opposite of inventors. Only an engineer can produce work that is truly new.
This is no different from my arguing that innovators are not inventors. Innovators improve, inventors create. They are NOT the same.
Software isn't the bottleneck. Caches are *tiny* compared to the size of even single functions in modern programs, which means they get flooded repeatedly, which in turn means that you're pulling from main memory a lot more than you'd like. Multi-core CPUs aren't (as a rule) fully independent - they share caches and share I/O lines, which in turn means that the effective capacity is slashed as a function of the number of active cores. Cheaper ones even share(d) the FPU, which was stupid. The bottleneck problem is typically solved by increasing the size of the on-chip caches OR by adding an external cache between main memory and the CPU. After that, it depends on whether the bottleneck is caused by bus contention or by slow RAM. Bus contention would require memory to be banked with each bank on an independent local bus. Slow RAM would require either faster RAM or smarter (PIM) RAM. (Smart RAM is RAM that is capable of performing very common operations internally without requiring the CPU. It's unpopular with manufacturers because they like cheap interchangeable parts and smart RAM is neither cheap nor interchangeable.)
Really, the entire notion of a CPU - or indeed a GPU - is getting tiresome. I liked the Transputer way of doing things (System-on-a-Chip architecture) and I still like that way of doing things. The Transputer had some excellent ideas - it's a shame it took Inmos so long to design an FPU (and a crappy one at that) and given that the T400 had a 20MHz bus at a time most CPUs were running at 4MHz, it's a damn shame they failed to keep that lead through to the T9000.
What I'd like to see is a SoC where instead of discrete cores (uck!) you have banks of independent registers, pools of compute elements and hyperthreading such that the software can dynamically configure how to divide up the resources. There's nothing to stop you moving all the GPU logic you like into such a system. It's merely more pools of compute elements. Microcode is already in use and microcode is nothing more than software binding of compute elements to form instructions. (Hell, microcode was already common on some architectures back in the 80s and was available for microprocessors within a decade of their being invented.) There's nothing that says microcode HAS to be closed firmware from the manufacturer - let the OS do the linking. It's the OS' job to partition resources and it can do so on-the-fly as needs dictate - something a manufacturer firmware blob can't do. Put the first 4 gigs onto the SoC and have one MMU per core plus one spare, so that each core can independently access memory (provided they don't try to access the same page). The spare is for direct access to memory from the main bus without going through any CPU (required for RDMA, which most peripherals should be capable of these days).
Such a design, where the OS converts the true primitives into the primitives (ie: instruction set) useful for the tasks being performed, would allow you to add in any number of other true primitives. Since any microcode-driven CPU is essentially a software processor anyway, you can afford to put extra compute elements out there. Any element not needed would not be routed to. Real-estate isn't nearly as expensive as is claimed, as evidenced by the number of artistic designs chip manufacturers etch in. Those designs are dead space that can magically be afforded, but there's nothing to stop you from replacing them with the necessary inter-primitive buffering to build ever-more complex instructions from primitives without loss of performance. I'm willing to bet HPC would look a whole lot more impressive if BLAS and LAPACK functions were specifically in hardware rather than being hacked via a GPU.
Of course, SoC means larger chips. So? Intel was talking about wafer-scale processors several years back (remember their 80-core boast?) and production has only improved since then. The yield is high enough quality that this is practical and since the idea is to software-wire the internals it becomes trivial to bypass defects. T
Off-processor caches existed before on-processor caches. Moving it into the silicon was not what I'd call engineering, just geography. X64 pipelining is again nothing more than a logical extension of what was already done, X64 superscalar is just a logical extension of pipelining, and so on. It's all stepwise refinement, hacks onto the original design. Hacks are not a bad thing - the X64 is a very usable processor - but it's not engineering.
Intel was quite capable of writing a compiler for it, they chose not to write one that was any good. Make no mistake, it WAS a choice. Their software divisions (they have many) are a mess, their contractor rates are terrible and the politics are cruddy. However, these are all fixable. Now that Intel owns the CILK++ code, they have a better chance than ever of doing it right -- if they can be bothered. Compilers aren't rocket science.
As for the original Itanic - they could have made the Itanium 2 from the get go. Again, they chose not to, for political reasons likely. Again, it was a choice. The new Itanium, the Itanium 9300, actually looks like a credible contender for HPC - again, if they get the compiler right.
The AMD64 has 16 64-bit registers, which is merely a logical next step from the 8 32-bit registers of the prior generation. According to Wikipedia: AMD64 still has fewer registers than many common RISC ISAs (which typically have 32–64 registers) or VLIW-like machines such as the IA-64 (which has 128 registers). The "no execute bit" is new with the AMD64, but none of the other underlying components seem to be anything more than basic upgrades. Long mode is just a flat address table and you've been able to do flat addressing for a while. I see nothing else that is new. Indeed, since the SSE family uses 64-bit floats and the x87 supported 80-bit floats, I'd say there have been regressions.
TheAMD64 is not a "pure" 64-bit chip. It is a chip that operates in 64-bits but has an internal architecture that has not significantly changed since the days of the 4040. It has merely been scaled. Scaling is not engineering.
That's easy! "Thou" was singular "you" and "ye" was plural "you". The modern word "you" carries no information as to whether it is singular or plural. "You all" doesn't help, since that is still both singular and plural in South Carolina and other parts of the southern States.
A few other examples:
Zyxt - second-person singular past tense of "to see". Shew - plural of "show".
It is not possible to construct an unambiguous sentence using modern English that handles these. Not exactly sure when English lost the explicit neuter - you can work round that by using a a back reference to a previous noun and categorize it as an it - that's not exactly what I'd call clear but it is at least unambiguous. The lost forms, however, can't so easily be replaced. You'll always have ambiguity.
Slashdot Mirror
Reed-Solomon can correct bit errors, Turbo Codes can correct block errors, and if you also include a cryptographic hash of the packet you can determine if the corrections fixed the data or it is still corrupt. Depending on the bandwidth consumed by the actual data, you might be able to throw in a lot of error correction bits and even have the error correction checksummed and error-corrected.
The SPARC is crappy at floating-point and Oracle probably want to kill it anyway. I also can't afford a FPGA that'll take the entire open-sourced T2 code. Damn.
Sure you can - provided the problem can be divided amongst nodes efficiently (the communication is slower over clusters, so the more communication you need, the more tightly integrated you need the system). Oh, and provided you have space. Clusters don't scale linearly, so to get the same performance as a single CPU that can do four times as much (larger registers and more of them), you need more than four times as many CPUs. See Amdahl's Law for details.
Oh, and each node on the cluster needs its own OS, so instead of running one Linux kernel over a multi-core multi-way motherboard, you're now running multiple Linux kernels. Each one takes CPU and memory resources, so to get the same available CPU power you have to have extra nodes to cover the overhead.
I don't know why the fascination with GPUs - they're faster than CPUs for most maths problems, sure, but if you took just the maths portion and replaced the rendering portion with common maths primitives (bits of the BLAS library and maybe a chunk of FFTW) reimplemented in hardware, you'd have something that was SO much faster than any GPU. GPUs are only useful because they're there now and a proper maths co-processor isn't. I see no reason to be a slave to an inferior solution when a superior one could be built in short order whenever the chip manufacturers bother.
(And it is a case of them bothering. They've made maths co-processors before, it's no big deal, and SystemC makes it relatively easy to produce a first pass at hardware from a software description. The number of consumers who would buy a maths co-processor is limited and obviously only scientific software that uses the software libraries currently would be trivial to adapt to hardware implementations, so there's bugger all market incentive for them to bother, and that is ultimately why no such cores exist. There aren't enough scientific software users to justify the R&D or the production of a specialized processor, but there ARE enough gamers to justify building faster GPUs and so the technical community gets to use sub-optimal crap as a result.)
If it were the chip used in food mixers for processing iceberg lettuce, it would even be appropriate.
Which, IMHO, is utterly wrong, completely in violation of the spirit of what a trademark is and probably in technical violation of the written law but IANAL.
The first two books were good, I found the third one to be a big let-down and suspect that she was pressured into writing excessive sequels to series she wanted closed.
According to her blog, she had serious heart problems in mid August. It's hard to say if her stroke now is related, but it wouldn't surprise me.
She was still posting on her blog and replying to fans a few weeks ago. I think it is her relationship with the fans that kept her going, to be honest. I met her at WorldCon in Glasgow back in the 90s and she wasn't all that well then. But when she talked with those of us at the coffee clatch, her energy seemed boundless.
Doesn't matter if the chess program can look at a million more moves or a billion. Chess Grand Masters look at patterns and compute which patterns are better than other patterns, which means that the pattern itself is a function. The better the Grand Master, the better the evaluation function. You need only have a function that evaluates the permutation of pieces on the board to a degree that is greater than the computer's evaluation of the permutation of a billion moves. Since Chess is a Full Information Game, it is provable that, for one of the sides, an evaluation exists such that looking a single move ahead will guarantee a win or a draw against any defense and that the other side can always force a draw if a single error is made.
So, yes, it is because you're lazy. Have you tried to produce a superior evaluation method? Have you really analyzed the maths? No? Then you haven't applied the effort needed. It is not the computer that has won, it is you who has lost.
20 chefs? Critical Path Analysis will show you every single scheduling conflict, when it will occur, where it will occur and how it will occur. You can timetable everything to that, with the breaks needed to synchronize neatly plotted out for you. 20 threads on a CPA is trivial. A major project might easily have a hundred. A parallel execution plan? Why? CPA will tell you the scheduling. Ok, how to divide resources? Well, it's a linear problem, so Operational Research would work fine. You want to recombine the elements to be efficient and the tools for that exist and taught to first years.
It IS still just recipes, but if N recipes call for egg yolks to be mixed well, you might as well have one chef mixing all that the recipes require then dividing up the mix into the right proportions and not have 20 chefs doing exactly the same thing. It's not hard. You make it complicated by believing it's complicated. It isn't. What is complicated is changing your mindset from serialized Mrs Beaton cookery to parallelized cooking of the kind that was actually commonplace in early cultures. (There was a fascinating find recently in Mesoamerica of gigantic cookware used to prepare dishes using this form of parallelism.)
There may well be Maoris on Slashdot. You can't see tattoos over the Internet. Now, there are probably no Moa on Slashdot and I hope there are no Keas (they're terrorists, I tell you!), but that's ok, there are enough bird-brains as it is. I have great respect for the Maori and it is intensely sad that I lost all of my mementos from my year in New Zealand after a storage place fire.
Back to the issue at hand. It is completely reprehensible that a "common word" (because it IS a common word in New Zealand) can be trademarked at all. That is not acceptable, in and of itself. It is a flagrant abuse of the system, relying on the fact that Americans are not very up on foreign cultures. I am increasingly of the opinion that words should not be trademarkable at all. A "trademark" is, after all, first and foremost a mark. From the Sumerians to the Victorian English, this has been a stamp, a unique symbol that denotes the origin and guarantees authenticity. Arguably, the seals produced by stamps and signet rings serve the same function.
You can always make a new symbol. Creativity is endless. But you can't create a new language every time foreigners decide to trademark words from it.
Well, the Itanium version 3 isn't too bad on performance. I agree it devours watts the way... well, nothing quite consumes anything the way the Itanium soaks up watts. That is a major flaw. The clock speed is an interesting one - I'll accept it can't ramp the way Intel expected but certainly overclockers have brought the 5 GHz processors up to 7 GHz without losing stability. It just can't be done at current temperatures. That means they either need to switch entirely off air-cooled chips or they need to make a radical chip change.
The radical chip change isn't unreasonable. Adding insulation layers, stressing the silicon, switching to copper interconnects - these all allowed clock speeds to grow. Copper, however, isn't the best conductor - silver is. The problem there is that silver is a bastard to work with - the chemistry isn't as friendly and it's extremely soft. The heat transfer off the silicon to the heatsink is also not great - I'd have thought flooding the inside of the chip with Fluorinert and replacing the top part of the chip casing with something highly conductive might be a better option since you'd get better heat transfer than with an air gap and plastic. Much more expensive in materials and much more complex manufacture, so vastly reduced profit margin, but it should boost performance.
(The other choice - naked silicon - would lose heat the best but it's much much harder to get that right in a liquid cooled environment. It is done, but I'd challenge anyone to find a person crazy enough to build a robust machine that way any more.)
Then there's asynchronous designs. The AMULET series of processors are asynchronous SPARC processors, so you can build general-purpose CPUs of moderate complexity that are actually useful this way. It has not been proven that you could build a modern superscalar 64-bit CPU of equal or greater performance to modern synchronous processors using the asynchronous tools that exist. (If you want, you can try them. They're open source and listed on Freshmeat - sorry, Freecode.) It may solve the roadblock, so far it hasn't.
Sensitivity to signals and electron tunneling are other obstacles to increasing speed. Of course, there's nothing to say you HAVE to use electrons. There are optical switches today and it's commonplace to build transceivers into silicon these days. You'd need to go 3D on the design to fit everything in and have line-of-sight, but it could be done.
Wikipedia also states "The term VLIW, and the concept of VLIW architecture itself, were invented by Josh Fisher in his research group at Yale University in the early 1980s". So it's an idea that's older than any of Intel's development in the field. It's a simple evolutionary step from horizontal microcode, since the whole idea is to have instruction-level parallelism. The disadvantage of CISC over RISC is that RISC turns out to be much faster. However, most chips these days are hybrids of RISC and CISC, thus minimizing bus activity and maximizing processor utility. A sensible approach to VLIW is to also hybridize. VLIW is designed to permit instruction-level optimizing that is impossible with CISC by passing additional specific information. There's absolutely no need for the processor to actually process a VLIW instruction directly, since we know RISC is superior. Instead, reduce the RISC set further, to more elementary compute elements, and have the VLIW decompose to it.
That's one reason that the Itanium sparked a massive revolution in source-to-source compilation. These meta-compilers turned things like C code for the GCC into something that was (a) optimized and (b) often for another compiler.
Intel has not done itself any favours with the Itanium - if it truly wanted an upsurge in usage, they'd collaborate with something like Google's Summer of Code, hand out a number of free Itanium developer boards to students and open-source developers, and get a massive surge in development that way. Ten Itanium developer boards would be pocket money for Intel in comparison to the cost of the division they're running for the processor, but ten Itanium developers over 3 months could make serious inroads into eliminating defective GCC optimization assumptions.
It's ironic that GCC still has such defects, given that PGCC - the Intel branch of GCC - was rejected by the EGCS developers because it made defective optimization assumptions. Platform-specific assumptions may be valid but should be in the platform-specific portions of the back-end and pre-optimizations that conflict with the platform should be masked out. If multiple implementations of a platform differ in platform-specific optimizations, detect or flag and then use the correct specifics. If the current GCC developers aren't willing to pay attention to this portion of compiling, then maybe we need another EGCS-style takeover bid.
(In fact, most processor manufacturers might want to chip in together to get GCC optimization straightened out. It's a valuable compiler to get right since open source won't go away and it's less of a PR disaster if experiments in GCC end up flopping than experiments in commercial compilers.)
All designs have limitations. Nor would I claim that the Itanium is the greatest processor out there. It has some great ideas, the second iteration was actually a decent invention, and it shows some nice creative elements. The flaws in the concept could only be revealed by actually implementing it and - as Linux kernel developers keep pointing out - actually putting it out there to test. Developers can't put anything, hardware or software, through all the real-world experiences, only users can do that and despite the wide availability of test silicon or test kernel releases, users won't test until it's mainstream.
The legacy limitations of the x86 are a major hindrance to development. (Back when the 68040 was commonplace, you'd never have seen this kind of fanboi reaction to me disliking the x86. People saw the alternatives, used the alternative and loved the alternatives. It's only modern users who have no experience with the true power of real designs that you see this kind of clingy addiction to arcane and archaic legacy defects.)
I've programmed the StrongARM, the MIPS64, the UltraSPARC, the M68040, the T800 Transputer, the DEC Alpha and every 80x86 processor save the Crusoe at the instruction level. Oh, and most of the 80x87s as well, except for IIT's 80x87 which I'd have loved to use as it could process entire arrays in single instructions. I know the alternatives. I've used processors that have no registers at all, just a bank of on-board RAM that you could divide and use as you wished. I've seen stuff in processor designs that are beyond the comprehension of those who have never seen outside the PC world. All of these processors had flaws and some died because those flaws were retained for compatibility purposes. But nobody who has that kind of breadth of experience believes that the flaws you know are worth clinging to. It's better to strike out boldly and risk failing than to tepidly patch. Evolution always dead-ends, but revolution can continue indefinitely.
I dislike stagnation of any kind. Learn, grow, incorporate, then invent. That is the only long-term solution. That's as true of bus technology as CPU design. If I were to design a bus, I'd look at the lessons learned from VXI, HyperTransport 3.1 and PCI Express 3, I'd want to know what worked and what didn't, but I wouldn't clone any of them. What would be the point? You can't invent if you don't know why things work the way they do, but you should never re-invent the wheel. If it's worth inventing, it's worth inventing something the wheel can never be.
Sure you could have off-processor caches on the 4004. Nothing stopped you. The first off-processor caches in mainstream use were for the 8086 and they became commonplace with the 80186.
No, I do not regard the modern x86 as requiring engineering. What Seymour Cray did (design each new computer one transistor at a time) was engineering. The x86 architecture is mere evolution, a catalogue of stepwise refinements on an existing design. There has been no truly new x86 design beyond the first. Everything since then has merely taken some component that already existed and improved it. Engineering is holistic, not piecemeal. Engineering is also not backwards-compatible, but it is backwards-compatibility that makes the x86 as useful as it is. Engineering is about solving the problems in front of you, not emulating the solutions imagined to be best for problems that no longer apply. Engineering is inventive, creative and novel. It's fresh.
The x86 is none of these. It is a piece of superb craftsmanship, old skills honed by years of use and experience. It takes a craft master to put a modern x86 with all the components necessary into hardware. But a craftsman is not an engineer. A craftsman is an expert rooted in PAST experience and PAST knowledge, building on those and relying entirely on them as foundations for improvement.
An engineer is a scientist, not a craftsman. Engineers do not look at the past for guidance, they look at the future for opportunities. Craftsmen can produce reliable work but they cannot produce truly new work, it takes an inventive mind to do that and crafters are the absolute opposite of inventors. Only an engineer can produce work that is truly new.
This is no different from my arguing that innovators are not inventors. Innovators improve, inventors create. They are NOT the same.
Correct. 4 general-purpose for the 16-bit, 8 for the 32-bit and 16 for the 64-bit.
Been there, done that. I've been on OpenCores longer than you've been on Slashdot.
Software isn't the bottleneck. Caches are *tiny* compared to the size of even single functions in modern programs, which means they get flooded repeatedly, which in turn means that you're pulling from main memory a lot more than you'd like. Multi-core CPUs aren't (as a rule) fully independent - they share caches and share I/O lines, which in turn means that the effective capacity is slashed as a function of the number of active cores. Cheaper ones even share(d) the FPU, which was stupid. The bottleneck problem is typically solved by increasing the size of the on-chip caches OR by adding an external cache between main memory and the CPU. After that, it depends on whether the bottleneck is caused by bus contention or by slow RAM. Bus contention would require memory to be banked with each bank on an independent local bus. Slow RAM would require either faster RAM or smarter (PIM) RAM. (Smart RAM is RAM that is capable of performing very common operations internally without requiring the CPU. It's unpopular with manufacturers because they like cheap interchangeable parts and smart RAM is neither cheap nor interchangeable.)
Really, the entire notion of a CPU - or indeed a GPU - is getting tiresome. I liked the Transputer way of doing things (System-on-a-Chip architecture) and I still like that way of doing things. The Transputer had some excellent ideas - it's a shame it took Inmos so long to design an FPU (and a crappy one at that) and given that the T400 had a 20MHz bus at a time most CPUs were running at 4MHz, it's a damn shame they failed to keep that lead through to the T9000.
What I'd like to see is a SoC where instead of discrete cores (uck!) you have banks of independent registers, pools of compute elements and hyperthreading such that the software can dynamically configure how to divide up the resources. There's nothing to stop you moving all the GPU logic you like into such a system. It's merely more pools of compute elements. Microcode is already in use and microcode is nothing more than software binding of compute elements to form instructions. (Hell, microcode was already common on some architectures back in the 80s and was available for microprocessors within a decade of their being invented.) There's nothing that says microcode HAS to be closed firmware from the manufacturer - let the OS do the linking. It's the OS' job to partition resources and it can do so on-the-fly as needs dictate - something a manufacturer firmware blob can't do. Put the first 4 gigs onto the SoC and have one MMU per core plus one spare, so that each core can independently access memory (provided they don't try to access the same page). The spare is for direct access to memory from the main bus without going through any CPU (required for RDMA, which most peripherals should be capable of these days).
Such a design, where the OS converts the true primitives into the primitives (ie: instruction set) useful for the tasks being performed, would allow you to add in any number of other true primitives. Since any microcode-driven CPU is essentially a software processor anyway, you can afford to put extra compute elements out there. Any element not needed would not be routed to. Real-estate isn't nearly as expensive as is claimed, as evidenced by the number of artistic designs chip manufacturers etch in. Those designs are dead space that can magically be afforded, but there's nothing to stop you from replacing them with the necessary inter-primitive buffering to build ever-more complex instructions from primitives without loss of performance. I'm willing to bet HPC would look a whole lot more impressive if BLAS and LAPACK functions were specifically in hardware rather than being hacked via a GPU.
Of course, SoC means larger chips. So? Intel was talking about wafer-scale processors several years back (remember their 80-core boast?) and production has only improved since then. The yield is high enough quality that this is practical and since the idea is to software-wire the internals it becomes trivial to bypass defects. T
Off-processor caches existed before on-processor caches. Moving it into the silicon was not what I'd call engineering, just geography. X64 pipelining is again nothing more than a logical extension of what was already done, X64 superscalar is just a logical extension of pipelining, and so on. It's all stepwise refinement, hacks onto the original design. Hacks are not a bad thing - the X64 is a very usable processor - but it's not engineering.
Intel was quite capable of writing a compiler for it, they chose not to write one that was any good. Make no mistake, it WAS a choice. Their software divisions (they have many) are a mess, their contractor rates are terrible and the politics are cruddy. However, these are all fixable. Now that Intel owns the CILK++ code, they have a better chance than ever of doing it right -- if they can be bothered. Compilers aren't rocket science.
As for the original Itanic - they could have made the Itanium 2 from the get go. Again, they chose not to, for political reasons likely. Again, it was a choice. The new Itanium, the Itanium 9300, actually looks like a credible contender for HPC - again, if they get the compiler right.
The AMD64 has 16 64-bit registers, which is merely a logical next step from the 8 32-bit registers of the prior generation. According to Wikipedia: AMD64 still has fewer registers than many common RISC ISAs (which typically have 32–64 registers) or VLIW-like machines such as the IA-64 (which has 128 registers). The "no execute bit" is new with the AMD64, but none of the other underlying components seem to be anything more than basic upgrades. Long mode is just a flat address table and you've been able to do flat addressing for a while. I see nothing else that is new. Indeed, since the SSE family uses 64-bit floats and the x87 supported 80-bit floats, I'd say there have been regressions.
TheAMD64 is not a "pure" 64-bit chip. It is a chip that operates in 64-bits but has an internal architecture that has not significantly changed since the days of the 4040. It has merely been scaled. Scaling is not engineering.
If you want high-end processing, you can do more with the Itanium than you can with the X64 architecture.
That's easy! "Thou" was singular "you" and "ye" was plural "you". The modern word "you" carries no information as to whether it is singular or plural. "You all" doesn't help, since that is still both singular and plural in South Carolina and other parts of the southern States.
A few other examples:
Zyxt - second-person singular past tense of "to see".
Shew - plural of "show".
It is not possible to construct an unambiguous sentence using modern English that handles these. Not exactly sure when English lost the explicit neuter - you can work round that by using a a back reference to a previous noun and categorize it as an it - that's not exactly what I'd call clear but it is at least unambiguous. The lost forms, however, can't so easily be replaced. You'll always have ambiguity.
Locked up?
Neither should Oracle. Hell, in a perfect world, both companies would donate all their assets to responsible companies and then quit.