4 ms·

Agree. In a few years, we'll all have N cores on our desktops.

by simon_ 17y ago

lucifer 17y ago
This is something I've been looking into and I'm becoming convinced that given the wide range of (expert level competency in) domains required (memory models, processor architectures, concurrent data structures) to effectively address the issues, it is likely that after a short period of language/software layer solutions, the issues will be addressed at the hardware level. Its an intrinsically hard problem that I doubt can ever be made practical for the general (IT level) programmer community.
- patio11 17y ago
  I think the general (IT level) programmer community doesn't require more processing power to do their jobs than they would have had on a single core desktop in 1999, anyhow.
  - dnewcome 17y ago
    It may be true that programmers don't strictly require the power, but interesting things become possible when you can afford to waste a lot of power. This should be evident by looking at Rails etc. In another 10 years who knows what will be possible by wasting another 100x processing power?
  - tptacek 17y ago
    I don't think you could have comfortably done Rails dev on the typical 1999 workstation.
- fnid 17y ago
  It's endlessly hardwareable. What I mean is, every algorithm or solution designed with software can always, by definition be implemented in hardware, bringing vast improvements in performance and scalability. This will always happen as long as hardware continues to get faster and there is no reason to believe that it won't continue to get faster exponentially for the foreseeable future. Quantum computing, 3D processors, light based data storage, carbon nanotubes, dna circuits... Soon, we will have Databases and Web Servers implemented in hardware... When graphics was the rage, Intel put MMX in the CPU. Now we have two CPUs in the CPU, or four. We put SSL in hardware to speed that up. We can and do put it all in hardware eventually. There are already lots of instant hardware solutions you can burn with EEPROM, PLAs, and the like. I don't see any reason Intel or AMD won't let consumers upload programs to burn right into the silicon. It'll be like embroidering polo shirts.
  - lucifer 17y ago
    Of course, that's a given. This whole business with Ln caches and cache-line misses is a sort of déjà vu in scale (and now people are talking about MVCC and transactions at the memory level ;) So yes, any software system can be embodied in hardware, but when a problem is so fiendishly difficult and optimal solutions require (sophisticated) algorithms matched to hardware specifics, then the cost equation tips heavily in favor of hardware embodiment. A significant barrier to the n-core future is pedagogical and I'm guessing that will further tip the balance towards a systemic solution embodied in hardware to hide the concurrency issues.
    - fnid 17y ago
      Well, that will be okay. Do you want to spend your time building the game or writing ray tracing algorithms? You want to call Array.sort(), not write a sort. It just takes up time. It's interesting that CISC won out over RISC considering the conversation we are having. It's simpler for the builder. You can repeat yourself less. Imagine doing a quicksort in assembly. No way, right? Not today. Why?
      - nzmsv 17y ago
        CISC won over RISC? I think you meant that in reverse :)
        elai 17y ago
        Just look at the i86/x64 instruction sets + extensions. It's rather large.
        aaronblohowiak 17y ago
        x86 is king. a terrible, ugly and far past its prime king, but king none-the-less. Edit: The replies below are insightful, I should not have been so reductionist.
        nzmsv 17y ago
- simon_ 17y ago
  It's an intrinsically hard problem, but one that can't necessarily be solved at the hardware level. For a large number of processors on the right tasks, just getting instruction level parallelism (e.g.) is not even tiny bit as good as using an optimized algorithm.
  - lucifer 17y ago
    I understand and agree with you, but that is by definition accessible only to a very specialized expert group. The differentiation aspect of hardware is that it involves both logical and physical domains, where as software is limited to logic. We may require new approaches to hardware and architectures as the "intrinsic" aspect of the problem is very much rooted in underlying hardware architecture. (I also wouldn't be surprised at all if the initial successful applications of quantum computing are memory related.)
- ynniv 17y ago
  Said like a true C programmer.

Agree. In a few years, we'll all have N cores on our desktops.

by simon_ 17y ago

Agree. In a few years, we'll all have N cores on our desktops.

This is something I've been looking into and I'm becoming convinced that given the wide range of (expert level competency in) domains required (memory models, processor architectures, concurrent data structures) to effectively address the issues, it is likely that after a short period of language/software layer solutions, the issues will be addressed at the hardware level. Its an intrinsically hard problem that I doubt can ever be made practical for the general (IT level) programmer community.

patio11 17y ago
I think the general (IT level) programmer community doesn't require more processing power to do their jobs than they would have had on a single core desktop in 1999, anyhow.
- dnewcome 17y ago
  It may be true that programmers don't strictly require the power, but interesting things become possible when you can afford to waste a lot of power. This should be evident by looking at Rails etc. In another 10 years who knows what will be possible by wasting another 100x processing power?
- tptacek 17y ago
  I don't think you could have comfortably done Rails dev on the typical 1999 workstation.
fnid 17y ago
It's endlessly hardwareable. What I mean is, every algorithm or solution designed with software can always, by definition be implemented in hardware, bringing vast improvements in performance and scalability. This will always happen as long as hardware continues to get faster and there is no reason to believe that it won't continue to get faster exponentially for the foreseeable future. Quantum computing, 3D processors, light based data storage, carbon nanotubes, dna circuits... Soon, we will have Databases and Web Servers implemented in hardware... When graphics was the rage, Intel put MMX in the CPU. Now we have two CPUs in the CPU, or four. We put SSL in hardware to speed that up. We can and do put it all in hardware eventually. There are already lots of instant hardware solutions you can burn with EEPROM, PLAs, and the like. I don't see any reason Intel or AMD won't let consumers upload programs to burn right into the silicon. It'll be like embroidering polo shirts.
- lucifer 17y ago
  Of course, that's a given. This whole business with Ln caches and cache-line misses is a sort of déjà vu in scale (and now people are talking about MVCC and transactions at the memory level ;) So yes, any software system can be embodied in hardware, but when a problem is so fiendishly difficult and optimal solutions require (sophisticated) algorithms matched to hardware specifics, then the cost equation tips heavily in favor of hardware embodiment. A significant barrier to the n-core future is pedagogical and I'm guessing that will further tip the balance towards a systemic solution embodied in hardware to hide the concurrency issues.
  - fnid 17y ago
    Well, that will be okay. Do you want to spend your time building the game or writing ray tracing algorithms? You want to call Array.sort(), not write a sort. It just takes up time. It's interesting that CISC won out over RISC considering the conversation we are having. It's simpler for the builder. You can repeat yourself less. Imagine doing a quicksort in assembly. No way, right? Not today. Why?
    - nzmsv 17y ago
      CISC won over RISC? I think you meant that in reverse :)
      - elai 17y ago
        Just look at the i86/x64 instruction sets + extensions. It's rather large.
      - aaronblohowiak 17y ago
        x86 is king. a terrible, ugly and far past its prime king, but king none-the-less. Edit: The replies below are insightful, I should not have been so reductionist.
        nzmsv 17y ago
simon_ 17y ago
It's an intrinsically hard problem, but one that can't necessarily be solved at the hardware level. For a large number of processors on the right tasks, just getting instruction level parallelism (e.g.) is not even tiny bit as good as using an optimized algorithm.
- lucifer 17y ago
  I understand and agree with you, but that is by definition accessible only to a very specialized expert group. The differentiation aspect of hardware is that it involves both logical and physical domains, where as software is limited to logic. We may require new approaches to hardware and architectures as the "intrinsic" aspect of the problem is very much rooted in underlying hardware architecture. (I also wouldn't be surprised at all if the initial successful applications of quantum computing are memory related.)
ynniv 17y ago
Said like a true C programmer.