Abordnet

I'm talking about physical device engineering: lower wire resistance, low-k dielectrics, diagonal routing, more _layer_s of _meta_l.  I had my own pessimistic article to cite: http://www.us.design-reuse.com/articles/article5786.html James Meindl at the Georgia Institute of Technology, who has become an expert in predicting the impending impact of physical parameters on future IC generations, has taken on the interconnect problem. His analysis predicts 80 levels of _meta_l by 2014 if no architectural changes are made in circuit design. I wondered when people would see the light, so to speak, and switch from electrons to something sensible like photons.  My private correspondent didn't think that would happen anytime soon. Something sensible like photons?   Just for curiosity sake, how would you propose to make such a creature work? I'm not trying to slam you, just curious as to what you have in mind, if you have anything in mind. I gather you are trying to replace parts of the on-chip interconnect infrastructure?  How would you use Photons to replace/augment such an infrastructure? Line of sight doesn't seem practicable, so I'll set it aside for now, so transmitter/receiver _base_d on mirrored reflections? Or do we build optical conduits for on chip applications? More important to me is the question of what the latencies are through the electrical-optical transmitter/receivers. It seems that it may be profitable to go to optical system in the case of off chip interconnects, since the assumed latencies are at least an order of magnitude worse anyways, but my impression of the problem here has been the latency through the electro- optical interface. Has there been recent advances in circuits that latencies through these devices are now next to nothing?

More important to me is the question of what the latencies are through the electrical-optical transmitter/receivers. It seems that it may be profitable to go to optical system in the case of off chip interconnects, since the assumed latencies are at least an order of magnitude worse anyways, but my impression of the problem here has been the latency through the electro- optical interface. Has there been recent advances in circuits that latencies through these devices are now next to nothing? The google search photonics nanosecond switching speed turns up lots of neat stuff.  The _link_ http://www.eetimes.com/at/news/OEG20000807S0052 talks about the problems of using very short wavelength photons for optical circuits, but all you need to do to solve the chip real-estate problem is to modulate and detect on nanosecond time-scales so you can move data over long paths, and if there is some fundamental physics that makes that impossible, I'm not aware of it.   RM

The question remains: where best to expose the parallelism.  My best thought right now is for the programmer to give the compiler as much of a head start and as many hints as possible, for the compiler to do the same for the processor, and for the processor to provide at least some last-instant flexibility.  That pretty much covers all the _base_s, doesn't it? . It does. Determining these possibilities as early as possible, i.e. by the programmer before writing a single line of code is going to stay the most efficient way to handle the problem. OTOH, I have developed a healthy respect for all the ways in which hw can do stuff relatively easily (or at least very fast!), that would take a lot of effort/programming. I am thinking in particular about all the various forms of aliasing that hinders performance of C code. The EPIC solution of exposing all these features to the programmer, letting her insert early loads and explicit checks for aliasing has the advantage of making the intent very clear, but some form of speculative execution might be able to match or improve on it, without actually increasing ifetch bandwidth too badly. Terje

In article < This e-mail address is being protected from spam bots, you need JavaScript enabled to view it _link_.co.uk, This e-mail address is being protected from spam bots, you need JavaScript enabled to view it (John Dallman) writes: | | A separate problem, which isn't so very far away, is speed-of-light- | in-silicon. Take a McKinley, at just over 400mm^2. So, it's about 20mm | from side to side, and that's equivalent to 15GHz in vacuum, or 10GHz at | best in silicon. Yes, indeed.  See below. | The salvation for serial processors, oddly enough, might be Microsoft. | Since the desktop apps that they do so well aren't nearly as amenable to | multi-threading (to speed up their eye candy) as server software is, | they're going to keep up the pressure for faster serial processors for a | while. They'll have to stop, and start improving efficiency at some point, | but that cultural change might be hard to institute. In my view, that is the reason that we haven't moved already! In article < This e-mail address is being protected from spam bots, you need JavaScript enabled to view it , Benjamin Ylvisaker < This e-mail address is being protected from spam bots, you need JavaScript enabled to view it writes: | | We are definitely seeing the beginning of the end of Not-Moore's law | for conventional microprocessor designs.  A clear analysis: | http://citeseer.nj.nec.com/agarwal00clock.html Interesting.  Whether or not it is right, it shows that some people closer to the action share my suspicions | Do you mean tricks like arranging buffers and wire sizes in some crazy | way to make a wire that naïvely should have a delay of 800 picoseconds | actually have a delay of 600 picoseconds?  Or tricks like the whole | procession of micro-architectural enhancements (superscalar, branch | prediction, trace cache, etc.) that we have seen?  If the former, then | I believe that the mileage we can get out of those tricks is | distinctly limited.  If the latter, then it is much harder to predict | what creative people may come up with. I agree with that, and the remark applies more generally.  Most of the tricks used to reduce power and improve effective performance (whether in hardware or software) have limited scope.  It is not as if nobody has tackled the problems before! | Five, ten, twenty years is a long time.  Probably while the rest of | us are still trying to figure out how to formulate the problem in | software, Andy Glew and others like him will have solved it in | silicon and chips of the (possibly not-too-distant future) will be | spinning off threads on the fly. | | I doubt that such a solution could scale very well.  There is an | interesting parallel here with the superscalar versus VLIW debate. | The basic question when comparing those two ideas is, should it be the | programmer and/or compiler that figures out which instructions should | run in parallel or the hardware?  Now we're wondering the exact same | thing, but about entire threads, not just a couple of adjacent (or | nearly so) instructions.  I believe that the problem of deciding how | to spin off parallel threads from a single threaded instruction stream | and maintaining coherence between the threads is too hard to be solved | (with reasonable efficiency) in hardware.  I would be fascinated if | someone can provide some solid counter-evidence against my belief.... I doubt that anyone can, as I think you are right.  Where Robert Myers's solution could work is when the compiler generates a large number of very lightweight actions, and the hardware schedules them. In article < This e-mail address is being protected from spam bots, you need JavaScript enabled to view it , Robert Myers < This e-mail address is being protected from spam bots, you need JavaScript enabled to view it writes: | | I wondered when people would see the light, so to speak, and switch | from electrons to something sensible like photons.  My private | correspondent didn't think that would happen anytime soon. Yes.  The interest in photoelectronics in silicon and hybrid materials is at least partially fuelled by the desire to be able to use light guides for long-distance (on-chip) communication. | It's apparently been pretty hard to predict what creative people are | going to come up with in either case.  Past ends-of-the-road foreseen | have come and gone with barely a blip. And others have been predicted to be soluble, but have not been, often with a denial that the cause of the direction change was the problem. | There is a published Ph.D. dissertation by Haitham Akkary, of | Portland State University, that gives some algorithms and speedups for | various forms of implicit multithreading.  It looks quite promising. | Akkary reported average speedups of 20-30% and peak speedups of over | 80% on some benchmarks. Not very hopeful, I am afraid.  For a scalable solution, we need an average of 2-3 times, at least. | There are plans in the works to use asymmetric helper threads on | actual processors.  You can find stuff by googling on helper thread. It is an old trick. | The similarity to the VLIW problem is not accidental.  The problems in | exposing and exploiting almost any kind of parallelism are pretty much | the same (I can thank David Gay for this insight) and that's what made | me decide the VLIW problem (and EPIC) were worth studying, whether | VLIW and EPIC were really good ideas or not. Why?  The problems were already well understood - just not by the people promoting those technologies. | People usually save the I don't think it's going to scale argument | as their last line of defense.  You might have gone there a little | prematurely. . It's known as foresight The reason that I don't like Eggers's SMT model is that the scalability restrictions mean that it will never deliver enough of an advantage to counteract its problems, at least in my area.  Worse, it means that it will give continuing improvements for only a few years, whereupon the changing circumstances could well make it redundant. This is similar.  I don't see the use of hardware threads to speed up serial execution of current codes as scalable enough to be worth the effort of developing.  But I do see them as worthwhile if we can start to use programming paradigms that would be more suited to them. Regards, Nick Maclaren.

This is similar.  I don't see the use of hardware threads to speed up serial execution of current codes as scalable enough to be worth the effort of developing.  But I do see them as worthwhile if we can start to use programming paradigms that would be more suited to them. You are trying to look too far ahead.  One step at a time. RM

People usually save the I don't think it's going to scale argument as their last line of defense.  You might have gone there a little prematurely. . I hope that Nick is right that jumping to this conclusion is foresight on my part and not a blind spot. Cheers, Benjamin