I remember what my architecture professor asked the class: "how many of you have done multi-processor programming?", 2-3 hands raised. "how many of you actually like multi-processing programming?", none raised. judging by that, he made a prediction that by at least 5-10 more years, SMP is not going happen to the mainstream. He said that ever since the 70s people have been saying that SMP (or RISC for that matter) is the way but still here we are. of course physics will not be defeated and we will get there (unless that chemical/biological/dna based processings really take of). Also a note on compilers: one can argue that compilers should really bridge that gap from hardware architecture and programmers. However keep in minds that architecture and compiler designs are not develop in-sync (and that compiler people are programmers too https://www.sharkyforums.com/images/.../2005/06/5.gif). architectures have a very long time span considerations (including backward compatibility and roadmaps) so compilers will have to follow the architecture. Somehow it's hard for the big processor maker to built that real new and nice architecture. Once they've built it, they'd keep it for as long as possible. It would be very nice if the designs are developed together cleanly.Quote:
Originally posted by Arcadian:
[B]
In the future, I see faster systems doing the following.
1) Moving to IA64, or other non-x86 architecture. This will undoubtably be IA64, but I am opening myself to the possibility that IA64 might fail, and another architecture comes to fill its shoes. On this same topic, we'll call it 1b) Paralellize data. In other words, SMP configurations are good for now, but I see symmetric multiprocessing on the core level in the future. Read another post on this forum for more information, but I believe SMT and CMP to be the future. More paralellized code will also be necessary so that each of the processor cores and threads will be given data 'a plenty to sort through.
2) Integrating everything. Like I said, speed is only found on the die, and as soon as you move off of it, you face nature's wrath. So the solution is to integrate CPU, video, memory, I/O, and the kitchen sink all on to the very same die.
[B]
integrated memory and logic is actually pretty hard to manufacture although there are several products already (usually with small amount of memory). memory and logic actually have different manufacturing process. Manufacturers don't even sure which process is better, to integrate logic to memory or memory to logic.
One aspect that can be optimized is the OS. In a way the OS developments have fallen victim to architectural design paradigm much like the compilers (and no, it's not entirely microsoft's fault either https://www.sharkyforums.com/images/.../2005/06/5.gif). There are/were many many OS designs (and implementations) that are very efficient in terms of bus or disk or memory utilizations or filesystems for example. As someone already mentioned, OS system calls are very expensive and can be made a lot more efficient. A specialized network hardware company has special NICs & drivers that are very fast and bypass the OS so data can be copied (and used) without a lot of context switching by the OS. My other professor believes that in the not too distant future, in a LAN situation, a server with a lot of RAM actually can serve data (a lot) faster than local drives (he also predicts that ubiquitous wireless networking will happen as soon as we aliminated all those nasty road tunnels).
[This message has been edited by darkamage (edited October 21, 2000).]
[This message has been edited by darkamage (edited October 21, 2000).]
