7 ms·

concurrency models: erlang, scala, clojure, Haskell Parallel execution, map/reduce, hadoop, noSQL datastores;

by gtani 17y ago

simon_ 17y ago
Agree. In a few years, we'll all have N cores on our desktops.
- 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
  - 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.
maxklein 17y ago
This will be a niche area for few very good programmers. A general purpose developer should not risk this. If it does not pan out, then you've wasted a lot of time.
- keefe 17y ago
  it's not going to pan out because we're going to roll back to single cores?
  - aaronblohowiak 17y ago
    Frankly, the vast majority of applications don't have these classes of concurrency, capacity and computational concerns and can be adequately scaled in the traditional fashion.
    - keefe 17y ago
      Exactly what type of application are you referring to? Most server software does a lot of work in parallel. Many computationally complex algorithms are parallelizable to one degree or another. Video games usually have a lot of parallelizable number crunching, analytics very often run quite slowly, UI code requires at least a couple threads of execution, on and on goes the list... it's time to adapt the idea of traditional to include more than sequential programs
      - aaronblohowiak 17y ago
        I presume that most applications that most people use most of the time do not need to scale. Most websites don't need to scale, most business apps don't need to scale, and most userland applications don't need to scale. Single-core sequential programs do just fine on comparatively resource constrained hardware for "everyday" applications. with the exception of maintaining a separate thread for UI, the examples you gave are edge cases. I am into game dev, music dsp and highly concurrent web application development... but I recognize that these are all fringe activities.

concurrency models: erlang, scala, clojure, Haskell Parallel execution, map/reduce, hadoop, noSQL datastores;

by gtani 17y ago

concurrency models: erlang, scala, clojure, Haskell Parallel execution, map/reduce, hadoop, noSQL datastores;

simon_ 17y ago

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

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
- 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.

maxklein 17y ago

This will be a niche area for few very good programmers. A general purpose developer should not risk this. If it does not pan out, then you've wasted a lot of time.

keefe 17y ago
it's not going to pan out because we're going to roll back to single cores?
- aaronblohowiak 17y ago
  Frankly, the vast majority of applications don't have these classes of concurrency, capacity and computational concerns and can be adequately scaled in the traditional fashion.
  - keefe 17y ago
    Exactly what type of application are you referring to? Most server software does a lot of work in parallel. Many computationally complex algorithms are parallelizable to one degree or another. Video games usually have a lot of parallelizable number crunching, analytics very often run quite slowly, UI code requires at least a couple threads of execution, on and on goes the list... it's time to adapt the idea of traditional to include more than sequential programs
    - aaronblohowiak 17y ago
      I presume that most applications that most people use most of the time do not need to scale. Most websites don't need to scale, most business apps don't need to scale, and most userland applications don't need to scale. Single-core sequential programs do just fine on comparatively resource constrained hardware for "everyday" applications. with the exception of maintaining a separate thread for UI, the examples you gave are edge cases. I am into game dev, music dsp and highly concurrent web application development... but I recognize that these are all fringe activities.