You are neglecting the fact that yield is dependent on die size. Therefore your "eventually" will depend on die size and you can easily run into the problem that your design is outdated (meaning you can only ask a low price for you chips) by the time your yield is acceptable.
This is true; however, the limit is still pretty high, because part of the development of a new linewidth is tweaking of the process until adequate reliability for large dies is obtained. The customers want to be able to produce large, fancy chips, so the fab houses tailor their processes accordingly.
You can also get a bit of leeway by using more conservative design rules when laying out your chip, though this usually has the side effect of making the chip slower.
Note: All of this just applies to the size of the core, not the entire die. Most of the die is cache, which is very easy to build in a fault-tolerant manner (more rows are included than are needed, and during initial testing, faulty rows are permanently isolated from the circuit).
There is a considerable amount of research on building chips that can function despite design or fabrication faults, which should make the problem much less severe in the future (yet another thing that I have to study as a degree project). This is needed not because of the yields, but because designing a billion-transistor chip without making critical mistakes may not be practical.
Is the Pentium II a descendant of the P-Pro? I thought Intel dumped the idea of doing CISC to RISC conversions. Obviously the PII takes some of the ideas of the P-Pro, but wasn't the defining feature of the P-Pro the fact that it was a RISC chip masquerading as a CISC? And if so, is the PII like that?
Pretty much all modern x86 chips, not just Intel's, are implemented this way. CISC instructions are very difficult to pipeline, which is why this technique was introduced (with one of the VAX chips, IIRC; neither Intel nor AMD nor NextGen invented it).
The Athlon is going to hit a speed bump because it puts out so much heat. You can't sell a processor which takes 95 degrees, so they won't even be able to do 1.5 GHz unless they radically modify the core (... Palomino is supposed to; we'll see).
Actually, linewidth shrinks can still be done. Power dissipation is proportional to the capacitance being charged and discharged, which is proportional to the area of the core (I'm ignoring the cache, which can be partitioned so as to scale without additional heat generation). For a given core layout, power dissipation at a given clock rate goes down as the square of the linewidth.
As clock rate is also determined by capacitance, it goes up by at most the same amount, resulting in a worst-case power dissipation the same as before the shrink - with a processor that runs much faster.
That having been said, reducing heat production will still allow you to increase the clock rate (you'd raise the clock speed, which in turn might require raising the core voltage, until the power dissipation was again at your maximum acceptable threshold).
As for the P4... Part of the reason it runs so cool is that it has a heat sink the size of Alaska sitting on top of it. What are its actual power consumption figures? These are a better basis for comparison.
If what you say is true, then i should be able to take an R3000 and with a sufficiently small die size and make it go 3 ghz.
But I can't.
Sure you can.
Later chips just add features that the old chip didn't support, or redesign functional units to work more efficiently. Thus, as they're more useful and silicon (below a certain area threshold) is cheap, the later chips are used.
One example: The R3000 has an in-order pipeline. The R10000 has an out-of-order pipeline. This means that the R10000 can keep on crunching in cases where the R3000 would be stalled.
Other differences exist, but I'm having a surprising amount of difficulty finding documentation on the MIPS cores' features on the web.
I wonder if this is entirely true. I have no knowledge of chip design and layout issues but it seems to me that sheer interest in advanced features wouldn't push Intel to P4-like processors. It is twice the size of P3, which means less chips per wafer and less yeild.
It turns out that a few points make it more attractive to use a more complex core:
A huge chunk of that die space is cache.
This means that making the processor core itself larger doesn't have as big an impact on the size of the chip as a whole as one might think.
Cost of the dies doesn't dominate in the endgame.
When yields approach reasonable ranges, as they always do eventually, the cost of an individual chip drops dramatically. Most of the cost of a module is support cost for the company that produced it, as opposed to raw silicon cost. While the die cost is still significant - especially when you're still fine-tuning and have low yields - chip size isn't as big a problem as it might first appear to be.
Cache has saturated - to build a faster chip, you need a better architecture.
We've reached the point where adding more cache to a chip doesn't help very much (for many applications, at least). Thus, the only way to get a performance gain over one's competitors is to produce a chip that has a higher clock rate for a given linewidth, or that can find more instructions to issue per clock, or both. To do this requires a redesign. We're nowhere near having a perfect design yet; there are always new things that can be added, especially as linewidth shrinks and transistor counts rise. So, redesign remains a useful way of improving performance.
In summary, the cost of using more transistors actually isn't that high, and the benefits of a redesign using these transistors are potentially great. So, the new cores continue.
Now, the chips might have seemed faster than their predecessors, but I'm betting you only bought them after a lot of code had been re-compiled. The Pentium Pro was slower, clock-for-clock, then the Pentium. It ran 16-bit code REALLY slowly, compared to Pentiums(which is why PPros never really entered the home-PC market).
Actually, for the older Intel chips (8086 to 80486), he's definitely correct. I had an old x86 assmebly manual at one point that listed instruction latencies in clock cycles for each of these processors - the latencies on the old chips weren't funny.
As far as I can tell, what happened was the newer chips had more transistors to play with, and so could implement more efficient (but bigger) functional units for operations. This would be especially noticeable for things like multiplication (software vs. shift-and-add vs. other methods).
As for the late end of that spectrum... The 486, if I recall correctly, was the first x86 chip to support pipelining. This made a *huge* difference, as was probably one of the driving factors behind the huge increase in clock speed that occurred with that chip (though linewidth shrinks would have helped). Effective latency for a lot of instructions went down to 1 clock, and clock period went down to the delay of one pipeline stage.
The Pentium introduced superscaling - a badly implemented dual-issue pipe, but a dual-issue pipe nonetheless. Code with instructions in the right order would execute up to twice as fast as in an equivalently-clocked 486 (though ordering it was difficult and annoying, due to many restrictions).
The Pentium Pro had a much better superscaling architecture - four pipelines, for handling different types of micro-op, and far fewer restrictions on what could be issued at the same time. It also broke CISC instructions into RISC-ian primitives for execution, which made superscaling much easier. While there wouldn't be a quantum leap in performance over the Pentium, it should have gotten much closer to the theoretical factor-of-two-over-486 than the Pentium did on most code (even optimized code).
The Pentium MMX and the Pentium Pro were two divergent forks off of the Pentium - not successors to each other. The Pentium MMX used the old Pentium core with a larger cache and SIMD integer instructions. Not terribly noteworthy (though the cache definitely helped).
The Pentium II was basically a P-Pro with the SIMD instructions and a larger cache. More of an incremental polishing over the P-Pro than anything else.
Ditto the Pentium III, though the SIMD instructions it added were actually extremely useful (sped up graphics drivers that used software transformation by about 25% on average, if I remember Tom's benchmarks).
So, I can't find fault with any of the changes Intel made. The 32 vs. 16-bit thing was IMO a _good_ tradeoff, as it didn't sacrifice new performance for legacy support.
No idea how good the P4 architecture is; I only have detailed specs on the ones listed above. The trace cache is a good idea, though.
That's exactly the point. Intel will be able to get massive MHz out of this core, and it'll leave Athlons in the dust(unfortunatly). Athlons will only be able to clock so high, and then that's it. They won't get any faster, without staying an Athlon.
While the P4 will always be able to run at a higher clock at a given linewidth than an Athlon, this differential won't just keep growing - it levels off at a fixed ratio and stays there, regardless of how many linewidth shrinks each architecture gets.
This is just a reflection of how pipelining works. To do, say, a floating-point multiply, you have to run inputs through a block of logic. This logic block has a certain internal delay, that won't change. A pipelined processor breaks this block into smaller blocks, but the _total_ delay remains the same (actually, it gets worse, due to pipeline register overhead). Sell a case of Coke as four 6-packs or 24 individual cans, you still have the same amount of Coke.
The relative clock ratio between the machines is simply the ratio of the durations of the individual pipeline stages in each architecture (actually of the longest pipeline stage in each architecture). This ratio doesn't change as the design shrinks; the P4 still has j stages, and the Athlon still has k stages, and a multiply still takes a fixed amount of time to perform at that linewidth.
Now, how many stages you should have is an interesting optimization problem, but it's not relevant to this discussion (scaling of each of these two existing cores).
Linewidth shrinks can be applied to any processor, and will speed up each processor by the same factor (more or less). Differences are the result of different low-level implementations (static vs. dynamic logic, one-sided vs. differential signalling, manufacturing process differences, etc); not the result of large-scale architecture.
So, I have a lot of trouble with these claims that one design can scale farther than another; as far as I can tell, there's no reason why both couldn't scale as far as they wanted to.
The reason why we don't just keep shrinking the same design forever is that as more transistors become available, you have space to implement more complicated structures. Things like schedulers and branch- and data-predictors can work in any of a large number of ways, and some of the more interesting versions take huge numbers of transistors. Similarly, adding SIMD support only became practical recently. This is why designs change - not because of some magical clock speed beyond which the old ones can't run.
I have a BASc in Computer Engineering and am working on my Masters, so I've been studying this a fair bit:).
a massive Beowulf cluster seems pretty "big" and "iron" to me.
The term "big iron" (in my experiance, at least) usually refers to very large SMP machines (in my experience, at least). They're considerably more difficult to tune an OS for than clusters, mostly because memory and communications are laid out very strangely to allow both fast and high-bandwidth access by a huge number of processors. Supporting hardware failover and hot-swapping in these systems isn't a cakewalk either.
Linux, in various forms, has started to tackle these issues, but a kernel optimized for single-processor or small-count SMP machines won't work well on a huge SMP box, and vice versa.
The point is that Linux is currently still missing a lot of features that traditional big iron operating systems already have, and probably won't implement them very well without a code fork into "small iron" and "big iron" kernels (which actually would be a good thing, IMO).
Sorry, but this is not a good idea. The reason being that any call to any such driver requires two full context switches. One for the call and one for the return from the call. Since a context switch is monstrously expensive, compared to a simple method call (which is all it takes to do a driver call with the current architecture), it's a MAJOR speed bump.
My point was that it's probably necessary to do it despite the speed hit. Vendors are just starting to notice Linux now; we'll be seeing an explosion of hardware support some time soon. Many of these drivers will be badly written, and stability will suffer a *lot* if a driver crash can take down the rest of the kernel.
Now, regarding the speed hit. I think that it's possible, with clever programming, to mask most of the performance degradation. While individual calls to the driver will still have a high cost, you can minimize the number of calls that need to be made.
For things like mouse and keyboard drivers, that have dozens to hundreds of events per second, speed is a non-issue. Context switches aren't *that* slow.
Sound drivers are similarly not much of a problem. Modern sound cards have large on-board buffers, and only need new data a few dozen times per second - few driver calls needed. Similarly, if the block size is set to something reasonably large by *default* when writing to the driver, you won't lose much sending sound data _to_ it.
The big performance-eaters will be network and video drivers, as both have to deal with large amounts of data. Again, though, the logical way around the problem is to queue substantial amounts of data before sending it to the driver. Make the default driver access points operate on long lists of primitives (for graphics drivers) or large blocks of data (for network drivers), and *remove* single-primitive functions. Add sample code or a user-space library to handle queueing, that the user can use if they don't feel like writing their own queueing code. Add a "flush" command that can purge the queue. Problem solved; the number of driver calls drops greatly, thus making context-switching overhead much less relevant.
I hope you realize that this is a fundimental CPU design. If AMD wants the Athlon to go beyond 2GHz they will have to make a deeoper pipeline.
...Or move to a finer linewidth.
Pipelining lets you increase the clock rate at a given linewidth. It isn't a requirement for faster clock rates in general.
Sometimes it's a good idea to use a larger pipeline, and sometimes not. For a given linewidth, increasing the pipeline depth will increase the clock speed at the expense of mispredict penalty and hardware complexity and timing sensitivity. Sometimes the increase in clock speed is enough to offset the disadvantages, but beyond a certain point, a deeper pipeline makes performance _worse_. What pipeline depth makes sense depends on your branch predictor, your cache, and a few other things.
However, shrinking linewidth will always let you increase clock speed, regardless of pipeline depth. It gives a straight factor-of-x speedup of all logic, no matter how the pipeline of the chip is set up.
I've been studying this for five years, so I have a good idea of what the tradeoffs are:).
I've done driver development under Linux, and my main complaint is having to reboot after every test until I've stomped all of the pointer errors in the driver. Having driver modules live in their own processes would solve this problem, and would also add insurance against the Windows destabilization effect (half of the instability of Windows comes from buggy drivers scribbling over memory, and it's just a matter of time before the same thing happens to Linux).
Yes, this is already present in other operating systems, and yes, this would slow down driver functions with the overhead from additional context switching, but that doesn't change the fact that it's still a Good Thing for Linux to have.
You should even be able to do this without breaking most of the kernel programming interface. You'd just need to add extra functions for doing things like messing with PCI configuration space (which most drivers do, but few do extensively, so no great imposition here).
The above comment about running Windows under Linux on a mainframe wouldn't work, due to incompatible instruction sets, but it brings up an interesting possibility:
Has anyone tried writing a complete virtual processor/virtual peripheral system that performs dynamic binary translation between instruction sets?
The canonical way of doing this - just running the program on an emulated processor with the desired instruction set - is hideously slow. You can't cross-compile the whole program, as parts of it will be inextricably bound to architecture, but you should be able to translate 99.9% of it to native code on the desired target platform. This would provide a vast speed boost over a purely emulated solution.
You could even design the system to perform cross-compiling and optimization of the new machine code incrementally. Much as with Transmeta's translation technology, you'd perform profiling on the fly to give translation/optimization priority to the sections of code used most frequently.
The advantage to this? I'm not sure, but among other things it would let me run Sparc binaries from the university servers on the x86 machine on the desk in my cubicle, or play MOO on the Sun boxen.
Has anyone tried writing such a monster, with or without the "incremental" bit? What was the end result?
Whether or not this is a good idea depends mainly on your company's approach to business.
In the grand scheme of things, it won't help your competition much, as they'd just spend the time to develop their own in-house solutions anyways when they felt the need. The practical effect of releasing the spec is that you've made a fixed, one-time donation of manpower to your competitors (they no longer have to develop their own versions of this spec).
On the other hand, there is little direct benefit to you releasing the spec. Some groups will adopt it, others won't, and you'll still have to spend a lot of time beating on your customers to use it properly. The good news is that a), free/open tools to perform conversion to/from common formats may become available, which reduces your support load to your customers (you'd otherwise have to provide the tools yourselves), and b) the spec may be extended by others when shortcomings are noticed. This is a benefit - you get R&D for free.
In practice neither effect is likely to be large unless you get lucky/unlucky. Your competitors will probably develop their own in-house specs tailored to their own needs anyways, and unless this is spectacularly useful, the Open Source and Free Software communities are unlikely to glom on to it to the extent required for free (beer) tools and an improved spec to appear.
What will determine whether management approves/disapproves this idea is a) whether their optimistic about the OSS/FS community's ability to spontaneously produce tools, and b) how cagey they are about their "intellectual property". Most likely scenario: They'll see no benefit and some potential loss, and more importantly see a chunk of their IP hanging out there for the world to see. Project not approved.
But, IMO it's still worth a shot, as long as you state your justifications carefully and do your research.
OK, so you restrict yourself to using the not "obscure aspects" of C++. Why not just keep using C?
Because there are a number of problems for which object-orienting is the most natural solution, and it makes sense to use a language that has native OO support to implement that solution.
Use C++ where it makes sense to do so. Forcing everyone to use ANSI C is just as silly as claiming that *everything* should be OO. Each has a problem domain to which it is suited, and widget toolkits just happen to lend themselves to an OO implementation.
Yes, you could use function pointers a la GTK, but that gets messy and annoying to maintain as your project changes and grows. I've been there.
Where is the problem with using C++ for an OO task?
Who cares?
Or is this now Slashdot - news for Astrophysicists?
Um, you *do* have the option of excluding "space" from your list of categories to be displayed. hit the "preferences" link on the left of your screen.
And as the astrophyics stories get a fair number of on-topic posts once they've been up for a while, I'd say that a significant segment of the slashdot readership is interested in them.
I know that no such negative index materials exists for optical wavelengths, but if it did, would this improve the resolution of lithography techniques used to etch chips? Or are the limitations in lithography due to diffraction effects with the chip masks?
If they're postulating a system at all where you can resolve images of features smaller than you should be able to, then they've solved all of the diffraction issues they need to. Though that's a big "if".
If they haven't, then this whole article is a non-issue, as there would be no way for anyone or anything to _observe_ the images of the finer features.
If we postulate that this problem is solved or is solvable, then it would indeed make a *huge* difference to lithography - a fair chunk of the expense is retooling to use new resists and other chemicals that work with the new wavelengths of light being used. Developing these chemicals is a *BIG* problem in moving to finer linewidths (though it's been done adequately so far). Magically produce optics that work with the same old wavelength of light, and you've saved a huge chunk of the R&D and fab upgrade expense.
I always thought that the resolution limits for a given wavelength were beacuse of the "effective size" of the photon. For example, a 150MHz photon could only resolve features larger than about 2 meters, it's wavelength.
This is an oversimplification, though it's still useful for rough estimates.
The versions I've heard - which deal with diffraction of light when passing through an aperture - almost certainly still hold. They're as follows:
Beam waist limits.
The spot size to which light may be focused in a beam converging with a given angle - and by symmetry, the smallest spot that may be accurately resolved with the same lens or mirror system - is simply the aperture size that would cause light passing through it to diffract out at the angle in question. This imposes a limit of about one wavelength to feature size (give or take).
Diffraction through the lens aperture.
Your lens is presumably of finite size. This means that light passing through it will have some angular spreading due to diffraction, no matter how the lens works. This will cause uncertainties in where any given photon passing through the lens came from, which makes your object look blurry with the cumulative effect of all of the photons being received. Thus, for a lens of a given size and focal length, you have a limit to the feature size you can resolve.
For most cases, the two rules work out equivalently. The only exception I can think of would be a "lens" that was a curved surface enveloping the target, and even then you'd have diffraction limits to what happened to light that passed outside the lens. This is mainly an artifact of the way I stated the above rules, as opposed to any kind of breakdown.
Now, the paper's claims. Reading the abstract posted by another user, it looks like it *just might* be legit, as opposed to a math error in the calculations somewhere. It relies on funky analysis of EM propagation in the (spatial) frequency domain, which is mostly beyond my knowledge, but *might* turn out a result like this under the right conditions. However, it's triggering all of my "it turns out this doesn't happen" alarms.
Even if the assertation is correct, you'd still have things like the aperture size problem to deal with (using a bigger device doesn't help - it or at least parts of it are farther away from the subject, and distance and angular resolution scale at the same rate).
Also, will this be a good test of transmeta's performance finally?
Doubtful. Web surfing doesn't stress the processor much. What it'll probably be stressing is Netscape plugin code efficiency, when it stresses anything at all.
Actually, the growth rate [...] would be xponential, not geometric.
"Exponential" is a type of "Geometric", and is usually used as a synonym.
From dictionary.com:
Geometrical progression, a progression in which the terms increase or decrease by equal ratios, as the numbers [lbrace2]2, 4, 8, 16, 32, 6464, 32, 16, 8, 4, 2[rbrace2] by a continual multiplication or division by 2.
A few points don't seem to be getting across adequately:
This isn't about nanotech.
95% of the article describes the interesting things that will happen as ordinary technology advances, and attempts to show a likely path it will take. The nanotech paragraphs were just added for the sake of completeness (as I'd already been talking about microtech). They are largely irrelevant to the article.
The thesis of this article.
As it seems to have been missed my post people: The purpose of the article is to point out a _probable_ path that manufacturing technology will take in the near future, and examine its corollaries. I posted it because a) the corollaries are interesting, and b) most people don't think about the fact that mundane universal fabricators will exist long before nanotech ones.
I hope this clears up a few things.
And Hemos, why is this not showing up on the main page? I had to do a search to turn it up at all.
It doesn't matter how advanced the technology is, how cool it sounds, nor who helped design it. If there isn't a market need for the product, it's going to be hard to find people to integrate it. Crusoe offers somewhat higher battery performance at the cost of performance. Does the market want lower performance?
Apparently not. However, there are a couple of other markets that the Crusoe could target fairly easily, that may be more viable:
Emulation of ARM and other PDA processors.
Wouldn't it be nice to have a low-power chip that could run standard PDA application and OS code "natively" but with far more heft? The Crusoe could fit this niche easily. Add appropriate support to a pared down Linux or *BSD, and you could even run, say, PalmOS and Windows CE as two processes on the same PDA. This has potential.
Power-hungry but uber-performing desktops.
Code morphing is a wonderful idea. I've taken my share of compilers courses, so I know how sub-optimal most code is going to be. If you have OS support for profiling and incremental optimization on the fly without too much overhead, you could blow the competition out of the water. Right now people try to do that in silicon with complicated scheduling units, with limited success (I've had my share of VLSI courses, too).
In summary, I feel that Transmeta has a few useful markets still open to it.
If a manufacturer stops selling a title, why don't they partner with sites like this who are already making the title available, and come up with a licensing agreement? You can't buy Electronic Art's "Balance of Power" anymore. They're not making money. Why are they spending money to send out cease-and-desist letters? Where's the revenue stream? What's the business model?
My guess is that this is partly an "on principle" thing, but also largely an action to protect their character trademarks.
"Balance of Power" may not be selling copies, but if they cease to enforce trademarks on their characters/designs, the designs may become public domain. This would prevent them from releasing "Balance of Power VII" down the road - and worse, it would let someone *else* release it!
So, I can see where they're coming from (though I agree that it's a pain).
That said, I'm beginning to wonder how viable Sun will be in the future. Their newest processor, the UltraSparc III, at 600 Mhz is slower in both integer and floating point than a P3 800 (according to the spec2000 benchmark, www.specbench.org). Yeah, its more efficent per clock cycle, but when you realize that the cheapest workstation with a single USIII 600 in it costs 10k, and you can easily build a Dual P3 800 system for under 2k, you soon realize that for sheer processing power, Sun is up a creek without a paddle.
Where Sun wins against PCs is in the high end. Sun's chips and systems are designed to be very scalable; you'd have a lot of trouble building an x86-based SMP machine that worked as well with a thousand processors as a Starfire.
That having been said, Sun seems to be losing the price/performance war against the other makers of Big Iron. However, x86 is no threat (for the time being).
All of this applies to machines that must have good internal communications bandwidth. If communications bandwidth isn't an issue, then a cluster of cheap PCs with expensive network hardware will always win. YMMV.
Re:More useful books on software development
on
Death March
·
· Score: 2
I'll probably get flamed for saying this but I read "The Project Survival Guide" by published by the evil empire and thought it was helpfull in expressing the disasters that can happen. Maybe that was because Micro$oft get more disasters than most;)
Another excellent book from Microsoft Press was "Writing Solid Code". Go to your local bookstore, pick it up, open it at random, and read a few pages. You'll be impressed.
Slashdot Mirror
You are neglecting the fact that yield is dependent on die size. Therefore your "eventually" will depend on die size and you can easily run into the problem that your design is outdated (meaning you can only ask a low price for you chips) by the time your yield is acceptable.
This is true; however, the limit is still pretty high, because part of the development of a new linewidth is tweaking of the process until adequate reliability for large dies is obtained. The customers want to be able to produce large, fancy chips, so the fab houses tailor their processes accordingly.
You can also get a bit of leeway by using more conservative design rules when laying out your chip, though this usually has the side effect of making the chip slower.
Note: All of this just applies to the size of the core, not the entire die. Most of the die is cache, which is very easy to build in a fault-tolerant manner (more rows are included than are needed, and during initial testing, faulty rows are permanently isolated from the circuit).
There is a considerable amount of research on building chips that can function despite design or fabrication faults, which should make the problem much less severe in the future (yet another thing that I have to study as a degree project). This is needed not because of the yields, but because designing a billion-transistor chip without making critical mistakes may not be practical.
Is the Pentium II a descendant of the P-Pro? I thought Intel dumped the idea of doing CISC to RISC conversions. Obviously the PII takes some of the ideas of the P-Pro, but wasn't the defining feature of the P-Pro the fact that it was a RISC chip masquerading as a CISC? And if so, is the PII like that?
Pretty much all modern x86 chips, not just Intel's, are implemented this way. CISC instructions are very difficult to pipeline, which is why this technique was introduced (with one of the VAX chips, IIRC; neither Intel nor AMD nor NextGen invented it).
The Athlon is going to hit a speed bump because it puts out so much heat. You can't sell a processor which takes 95 degrees, so they won't even be able to do 1.5 GHz unless they radically modify the core (... Palomino is supposed to; we'll see).
Actually, linewidth shrinks can still be done. Power dissipation is proportional to the capacitance being charged and discharged, which is proportional to the area of the core (I'm ignoring the cache, which can be partitioned so as to scale without additional heat generation). For a given core layout, power dissipation at a given clock rate goes down as the square of the linewidth.
As clock rate is also determined by capacitance, it goes up by at most the same amount, resulting in a worst-case power dissipation the same as before the shrink - with a processor that runs much faster.
That having been said, reducing heat production will still allow you to increase the clock rate (you'd raise the clock speed, which in turn might require raising the core voltage, until the power dissipation was again at your maximum acceptable threshold).
As for the P4... Part of the reason it runs so cool is that it has a heat sink the size of Alaska sitting on top of it. What are its actual power consumption figures? These are a better basis for comparison.
If what you say is true, then i should be able to take an R3000 and with a sufficiently small die size and make it go 3 ghz.
But I can't.
Sure you can.
Later chips just add features that the old chip didn't support, or redesign functional units to work more efficiently. Thus, as they're more useful and silicon (below a certain area threshold) is cheap, the later chips are used.
One example: The R3000 has an in-order pipeline. The R10000 has an out-of-order pipeline. This means that the R10000 can keep on crunching in cases where the R3000 would be stalled.
Other differences exist, but I'm having a surprising amount of difficulty finding documentation on the MIPS cores' features on the web.
It turns out that a few points make it more attractive to use a more complex core:
This means that making the processor core itself larger doesn't have as big an impact on the size of the chip as a whole as one might think.
When yields approach reasonable ranges, as they always do eventually, the cost of an individual chip drops dramatically. Most of the cost of a module is support cost for the company that produced it, as opposed to raw silicon cost. While the die cost is still significant - especially when you're still fine-tuning and have low yields - chip size isn't as big a problem as it might first appear to be.
We've reached the point where adding more cache to a chip doesn't help very much (for many applications, at least). Thus, the only way to get a performance gain over one's competitors is to produce a chip that has a higher clock rate for a given linewidth, or that can find more instructions to issue per clock, or both. To do this requires a redesign. We're nowhere near having a perfect design yet; there are always new things that can be added, especially as linewidth shrinks and transistor counts rise. So, redesign remains a useful way of improving performance.
In summary, the cost of using more transistors actually isn't that high, and the benefits of a redesign using these transistors are potentially great. So, the new cores continue.
Now, the chips might have seemed faster than their predecessors, but I'm betting you only bought them after a lot of code had been re-compiled. The Pentium Pro was slower, clock-for-clock, then the Pentium. It ran 16-bit code REALLY slowly, compared to Pentiums(which is why PPros never really entered the home-PC market).
Actually, for the older Intel chips (8086 to 80486), he's definitely correct. I had an old x86 assmebly manual at one point that listed instruction latencies in clock cycles for each of these processors - the latencies on the old chips weren't funny.
As far as I can tell, what happened was the newer chips had more transistors to play with, and so could implement more efficient (but bigger) functional units for operations. This would be especially noticeable for things like multiplication (software vs. shift-and-add vs. other methods).
As for the late end of that spectrum... The 486, if I recall correctly, was the first x86 chip to support pipelining. This made a *huge* difference, as was probably one of the driving factors behind the huge increase in clock speed that occurred with that chip (though linewidth shrinks would have helped). Effective latency for a lot of instructions went down to 1 clock, and clock period went down to the delay of one pipeline stage.
The Pentium introduced superscaling - a badly implemented dual-issue pipe, but a dual-issue pipe nonetheless. Code with instructions in the right order would execute up to twice as fast as in an equivalently-clocked 486 (though ordering it was difficult and annoying, due to many restrictions).
The Pentium Pro had a much better superscaling architecture - four pipelines, for handling different types of micro-op, and far fewer restrictions on what could be issued at the same time. It also broke CISC instructions into RISC-ian primitives for execution, which made superscaling much easier. While there wouldn't be a quantum leap in performance over the Pentium, it should have gotten much closer to the theoretical factor-of-two-over-486 than the Pentium did on most code (even optimized code).
The Pentium MMX and the Pentium Pro were two divergent forks off of the Pentium - not successors to each other. The Pentium MMX used the old Pentium core with a larger cache and SIMD integer instructions. Not terribly noteworthy (though the cache definitely helped).
The Pentium II was basically a P-Pro with the SIMD instructions and a larger cache. More of an incremental polishing over the P-Pro than anything else.
Ditto the Pentium III, though the SIMD instructions it added were actually extremely useful (sped up graphics drivers that used software transformation by about 25% on average, if I remember Tom's benchmarks).
So, I can't find fault with any of the changes Intel made. The 32 vs. 16-bit thing was IMO a _good_ tradeoff, as it didn't sacrifice new performance for legacy support.
No idea how good the P4 architecture is; I only have detailed specs on the ones listed above. The trace cache is a good idea, though.
That's exactly the point. Intel will be able to get massive MHz out of this core, and it'll leave Athlons in the dust(unfortunatly). Athlons will only be able to clock so high, and then that's it. They won't get any faster, without staying an Athlon.
:).
While the P4 will always be able to run at a higher clock at a given linewidth than an Athlon, this differential won't just keep growing - it levels off at a fixed ratio and stays there, regardless of how many linewidth shrinks each architecture gets.
This is just a reflection of how pipelining works. To do, say, a floating-point multiply, you have to run inputs through a block of logic. This logic block has a certain internal delay, that won't change. A pipelined processor breaks this block into smaller blocks, but the _total_ delay remains the same (actually, it gets worse, due to pipeline register overhead). Sell a case of Coke as four 6-packs or 24 individual cans, you still have the same amount of Coke.
The relative clock ratio between the machines is simply the ratio of the durations of the individual pipeline stages in each architecture (actually of the longest pipeline stage in each architecture). This ratio doesn't change as the design shrinks; the P4 still has j stages, and the Athlon still has k stages, and a multiply still takes a fixed amount of time to perform at that linewidth.
Now, how many stages you should have is an interesting optimization problem, but it's not relevant to this discussion (scaling of each of these two existing cores).
Linewidth shrinks can be applied to any processor, and will speed up each processor by the same factor (more or less). Differences are the result of different low-level implementations (static vs. dynamic logic, one-sided vs. differential signalling, manufacturing process differences, etc); not the result of large-scale architecture.
So, I have a lot of trouble with these claims that one design can scale farther than another; as far as I can tell, there's no reason why both couldn't scale as far as they wanted to.
The reason why we don't just keep shrinking the same design forever is that as more transistors become available, you have space to implement more complicated structures. Things like schedulers and branch- and data-predictors can work in any of a large number of ways, and some of the more interesting versions take huge numbers of transistors. Similarly, adding SIMD support only became practical recently. This is why designs change - not because of some magical clock speed beyond which the old ones can't run.
I have a BASc in Computer Engineering and am working on my Masters, so I've been studying this a fair bit
a massive Beowulf cluster seems pretty "big" and "iron" to me.
The term "big iron" (in my experiance, at least) usually refers to very large SMP machines (in my experience, at least). They're considerably more difficult to tune an OS for than clusters, mostly because memory and communications are laid out very strangely to allow both fast and high-bandwidth access by a huge number of processors. Supporting hardware failover and hot-swapping in these systems isn't a cakewalk either.
Linux, in various forms, has started to tackle these issues, but a kernel optimized for single-processor or small-count SMP machines won't work well on a huge SMP box, and vice versa.
The point is that Linux is currently still missing a lot of features that traditional big iron operating systems already have, and probably won't implement them very well without a code fork into "small iron" and "big iron" kernels (which actually would be a good thing, IMO).
Sorry, but this is not a good idea. The reason being that any call to any such driver requires two full context switches. One for the call and one for the return from the call. Since a context switch is monstrously expensive, compared to a simple method call (which is all it takes to do a driver call with the current architecture), it's a MAJOR speed bump.
My point was that it's probably necessary to do it despite the speed hit. Vendors are just starting to notice Linux now; we'll be seeing an explosion of hardware support some time soon. Many of these drivers will be badly written, and stability will suffer a *lot* if a driver crash can take down the rest of the kernel.
Now, regarding the speed hit. I think that it's possible, with clever programming, to mask most of the performance degradation. While individual calls to the driver will still have a high cost, you can minimize the number of calls that need to be made.
For things like mouse and keyboard drivers, that have dozens to hundreds of events per second, speed is a non-issue. Context switches aren't *that* slow.
Sound drivers are similarly not much of a problem. Modern sound cards have large on-board buffers, and only need new data a few dozen times per second - few driver calls needed. Similarly, if the block size is set to something reasonably large by *default* when writing to the driver, you won't lose much sending sound data _to_ it.
The big performance-eaters will be network and video drivers, as both have to deal with large amounts of data. Again, though, the logical way around the problem is to queue substantial amounts of data before sending it to the driver. Make the default driver access points operate on long lists of primitives (for graphics drivers) or large blocks of data (for network drivers), and *remove* single-primitive functions. Add sample code or a user-space library to handle queueing, that the user can use if they don't feel like writing their own queueing code. Add a "flush" command that can purge the queue. Problem solved; the number of driver calls drops greatly, thus making context-switching overhead much less relevant.
I hope you realize that this is a fundimental CPU design. If AMD wants the Athlon to go beyond 2GHz they will have to make a deeoper pipeline.
:).
...Or move to a finer linewidth.
Pipelining lets you increase the clock rate at a given linewidth. It isn't a requirement for faster clock rates in general.
Sometimes it's a good idea to use a larger pipeline, and sometimes not. For a given linewidth, increasing the pipeline depth will increase the clock speed at the expense of mispredict penalty and hardware complexity and timing sensitivity. Sometimes the increase in clock speed is enough to offset the disadvantages, but beyond a certain point, a deeper pipeline makes performance _worse_. What pipeline depth makes sense depends on your branch predictor, your cache, and a few other things.
However, shrinking linewidth will always let you increase clock speed, regardless of pipeline depth. It gives a straight factor-of-x speedup of all logic, no matter how the pipeline of the chip is set up.
I've been studying this for five years, so I have a good idea of what the tradeoffs are
I've done driver development under Linux, and my main complaint is having to reboot after every test until I've stomped all of the pointer errors in the driver. Having driver modules live in their own processes would solve this problem, and would also add insurance against the Windows destabilization effect (half of the instability of Windows comes from buggy drivers scribbling over memory, and it's just a matter of time before the same thing happens to Linux).
Yes, this is already present in other operating systems, and yes, this would slow down driver functions with the overhead from additional context switching, but that doesn't change the fact that it's still a Good Thing for Linux to have.
You should even be able to do this without breaking most of the kernel programming interface. You'd just need to add extra functions for doing things like messing with PCI configuration space (which most drivers do, but few do extensively, so no great imposition here).
The above comment about running Windows under Linux on a mainframe wouldn't work, due to incompatible instruction sets, but it brings up an interesting possibility:
Has anyone tried writing a complete virtual processor/virtual peripheral system that performs dynamic binary translation between instruction sets?
The canonical way of doing this - just running the program on an emulated processor with the desired instruction set - is hideously slow. You can't cross-compile the whole program, as parts of it will be inextricably bound to architecture, but you should be able to translate 99.9% of it to native code on the desired target platform. This would provide a vast speed boost over a purely emulated solution.
You could even design the system to perform cross-compiling and optimization of the new machine code incrementally. Much as with Transmeta's translation technology, you'd perform profiling on the fly to give translation/optimization priority to the sections of code used most frequently.
The advantage to this? I'm not sure, but among other things it would let me run Sparc binaries from the university servers on the x86 machine on the desk in my cubicle, or play MOO on the Sun boxen.
Has anyone tried writing such a monster, with or without the "incremental" bit? What was the end result?
Whether or not this is a good idea depends mainly on your company's approach to business.
In the grand scheme of things, it won't help your competition much, as they'd just spend the time to develop their own in-house solutions anyways when they felt the need. The practical effect of releasing the spec is that you've made a fixed, one-time donation of manpower to your competitors (they no longer have to develop their own versions of this spec).
On the other hand, there is little direct benefit to you releasing the spec. Some groups will adopt it, others won't, and you'll still have to spend a lot of time beating on your customers to use it properly. The good news is that a), free/open tools to perform conversion to/from common formats may become available, which reduces your support load to your customers (you'd otherwise have to provide the tools yourselves), and b) the spec may be extended by others when shortcomings are noticed. This is a benefit - you get R&D for free.
In practice neither effect is likely to be large unless you get lucky/unlucky. Your competitors will probably develop their own in-house specs tailored to their own needs anyways, and unless this is spectacularly useful, the Open Source and Free Software communities are unlikely to glom on to it to the extent required for free (beer) tools and an improved spec to appear.
What will determine whether management approves/disapproves this idea is a) whether their optimistic about the OSS/FS community's ability to spontaneously produce tools, and b) how cagey they are about their "intellectual property". Most likely scenario: They'll see no benefit and some potential loss, and more importantly see a chunk of their IP hanging out there for the world to see. Project not approved.
But, IMO it's still worth a shot, as long as you state your justifications carefully and do your research.
OK, so you restrict yourself to using the not "obscure aspects" of C++. Why not just keep using C?
Because there are a number of problems for which object-orienting is the most natural solution, and it makes sense to use a language that has native OO support to implement that solution.
Use C++ where it makes sense to do so. Forcing everyone to use ANSI C is just as silly as claiming that *everything* should be OO. Each has a problem domain to which it is suited, and widget toolkits just happen to lend themselves to an OO implementation.
Yes, you could use function pointers a la GTK, but that gets messy and annoying to maintain as your project changes and grows. I've been there.
Where is the problem with using C++ for an OO task?
Yes, I'm burning karma doing this, but the AC has an extremely good point and has been sitting at 0 for a while now.
Who cares?
Or is this now Slashdot - news for Astrophysicists?
Um, you *do* have the option of excluding "space" from your list of categories to be displayed. hit the "preferences" link on the left of your screen.
And as the astrophyics stories get a fair number of on-topic posts once they've been up for a while, I'd say that a significant segment of the slashdot readership is interested in them.
I know that no such negative index materials exists for optical wavelengths, but if it did, would this improve the resolution of lithography techniques used to etch chips? Or are the limitations in lithography due to diffraction effects with the chip masks?
If they're postulating a system at all where you can resolve images of features smaller than you should be able to, then they've solved all of the diffraction issues they need to. Though that's a big "if".
If they haven't, then this whole article is a non-issue, as there would be no way for anyone or anything to _observe_ the images of the finer features.
If we postulate that this problem is solved or is solvable, then it would indeed make a *huge* difference to lithography - a fair chunk of the expense is retooling to use new resists and other chemicals that work with the new wavelengths of light being used. Developing these chemicals is a *BIG* problem in moving to finer linewidths (though it's been done adequately so far). Magically produce optics that work with the same old wavelength of light, and you've saved a huge chunk of the R&D and fab upgrade expense.
This is an oversimplification, though it's still useful for rough estimates.
The versions I've heard - which deal with diffraction of light when passing through an aperture - almost certainly still hold. They're as follows:
The spot size to which light may be focused in a beam converging with a given angle - and by symmetry, the smallest spot that may be accurately resolved with the same lens or mirror system - is simply the aperture size that would cause light passing through it to diffract out at the angle in question. This imposes a limit of about one wavelength to feature size (give or take).
Your lens is presumably of finite size. This means that light passing through it will have some angular spreading due to diffraction, no matter how the lens works. This will cause uncertainties in where any given photon passing through the lens came from, which makes your object look blurry with the cumulative effect of all of the photons being received. Thus, for a lens of a given size and focal length, you have a limit to the feature size you can resolve.
For most cases, the two rules work out equivalently. The only exception I can think of would be a "lens" that was a curved surface enveloping the target, and even then you'd have diffraction limits to what happened to light that passed outside the lens. This is mainly an artifact of the way I stated the above rules, as opposed to any kind of breakdown.
Now, the paper's claims. Reading the abstract posted by another user, it looks like it *just might* be legit, as opposed to a math error in the calculations somewhere. It relies on funky analysis of EM propagation in the (spatial) frequency domain, which is mostly beyond my knowledge, but *might* turn out a result like this under the right conditions. However, it's triggering all of my "it turns out this doesn't happen" alarms.
Even if the assertation is correct, you'd still have things like the aperture size problem to deal with (using a bigger device doesn't help - it or at least parts of it are farther away from the subject, and distance and angular resolution scale at the same rate).
Also, will this be a good test of transmeta's performance finally?
Doubtful. Web surfing doesn't stress the processor much. What it'll probably be stressing is Netscape plugin code efficiency, when it stresses anything at all.
Actually, the growth rate [...] would be xponential, not geometric.
"Exponential" is a type of "Geometric", and is usually used as a synonym.
From dictionary.com:
Geometrical progression, a progression in which the terms increase or decrease by equal ratios, as the numbers [lbrace2]2, 4, 8, 16, 32, 6464, 32, 16, 8, 4, 2[rbrace2] by a continual multiplication or division by 2.
(Their typos, not mine.)
95% of the article describes the interesting things that will happen as ordinary technology advances, and attempts to show a likely path it will take. The nanotech paragraphs were just added for the sake of completeness (as I'd already been talking about microtech). They are largely irrelevant to the article.
As it seems to have been missed my post people: The purpose of the article is to point out a _probable_ path that manufacturing technology will take in the near future, and examine its corollaries. I posted it because a) the corollaries are interesting, and b) most people don't think about the fact that mundane universal fabricators will exist long before nanotech ones.
I hope this clears up a few things.
And Hemos, why is this not showing up on the main page? I had to do a search to turn it up at all.
Apparently not. However, there are a couple of other markets that the Crusoe could target fairly easily, that may be more viable:
Wouldn't it be nice to have a low-power chip that could run standard PDA application and OS code "natively" but with far more heft? The Crusoe could fit this niche easily. Add appropriate support to a pared down Linux or *BSD, and you could even run, say, PalmOS and Windows CE as two processes on the same PDA. This has potential.
Code morphing is a wonderful idea. I've taken my share of compilers courses, so I know how sub-optimal most code is going to be. If you have OS support for profiling and incremental optimization on the fly without too much overhead, you could blow the competition out of the water. Right now people try to do that in silicon with complicated scheduling units, with limited success (I've had my share of VLSI courses, too).
In summary, I feel that Transmeta has a few useful markets still open to it.
If a manufacturer stops selling a title, why don't they partner with sites like this who are already making the title available, and come up with a licensing agreement? You can't buy Electronic Art's "Balance of Power" anymore. They're not making money. Why are they spending money to send out cease-and-desist letters? Where's the revenue stream? What's the business model?
My guess is that this is partly an "on principle" thing, but also largely an action to protect their character trademarks.
"Balance of Power" may not be selling copies, but if they cease to enforce trademarks on their characters/designs, the designs may become public domain. This would prevent them from releasing "Balance of Power VII" down the road - and worse, it would let someone *else* release it!
So, I can see where they're coming from (though I agree that it's a pain).
That said, I'm beginning to wonder how viable Sun will be in the future. Their newest processor, the UltraSparc III, at 600 Mhz is slower in both integer and floating point than a P3 800 (according to the spec2000 benchmark, www.specbench.org). Yeah, its more efficent per clock cycle, but when you realize that the cheapest workstation with a single USIII 600 in it costs 10k, and you can easily build a Dual P3 800 system for under 2k, you soon realize that for sheer processing power, Sun is up a creek without a paddle.
Where Sun wins against PCs is in the high end. Sun's chips and systems are designed to be very scalable; you'd have a lot of trouble building an x86-based SMP machine that worked as well with a thousand processors as a Starfire.
That having been said, Sun seems to be losing the price/performance war against the other makers of Big Iron. However, x86 is no threat (for the time being).
All of this applies to machines that must have good internal communications bandwidth. If communications bandwidth isn't an issue, then a cluster of cheap PCs with expensive network hardware will always win. YMMV.
I'll probably get flamed for saying this but I read "The Project Survival Guide" by published by the evil empire and thought it was helpfull in expressing the disasters that can happen. Maybe that was because Micro$oft get more disasters than most ;)
Another excellent book from Microsoft Press was "Writing Solid Code". Go to your local bookstore, pick it up, open it at random, and read a few pages. You'll be impressed.