5 ms·

That's ridiculous. Programming is not all about multi-core performance. it will be. you're getting beaten over the head by chip designers telling you that your

That's ridiculous. Programming is not all about multi-core performance. it will be. you're getting beaten over the head by chip designers telling you that your future cpu is going to consist of a (possibly large) array of processing cores with a high-capacity bus connecting them. they are telling you this is the only way they can give you higher performance. you had better start believing them because these systems are starting to get delivered now. A great example of that is Rails, when set up with mongrel processes, each of which can run on its own core if necessary ?????? so mongrel comes with its own OS kernel that has better support for multicore than linux and freebsd? wow!! coolzzz!

swombat 18y ago
I don't write OS kernels, I write rails application. I don't give a rat's ass about the OS kernel. I don't even give a rat's ass about how Mongrel is programmed. The Rails applications themselves don't need to be altered to run in a multi-core environment. Mongrel naturally scales to as many servers or CPUs as you want to run it on, since there is no interaction between different mongrel instances, all that happens at the database. Let me make that point even clearer: I don't give a shit how the database has been programmed. Someone there has obviously had to think about parallelism, but I don't need to, because I'm not writing a fricken database. Got it?
- crabapple 18y ago
  I don't write OS kernels, I write rails application. I don't give a rat's ass about the OS kernel then stop spouting off uninformed comments about how processes are scheduled The Rails applications themselves don't need to be altered to run in a multi-core environment. nor do any other program compiled for that architecture. its the OS that schedules processes, not your userland program. the point is, some programs can be written in a way that makes it easier for the OS to exploit multicore. since ruby is not a functional language, my guess is that it would tend to not help the kernel exploit these resources. but obviously in the worst case, a process can run inside one core and never get the advantages of the rest of the chip architecture. this is about exploiting multicore Got it? yes, i get that you know very little about how computers function
  - swombat 18y ago
    nor do any other program compiled for that architecture Then none of the people writing those programs need to know or care about parallelism. Therefore, the core message of the article is brain-dead.
    - crabapple 18y ago
      NO. why don't you READ before you reply a program compiled for a multicore CPU will RUN. the question is how OPTIMALLY does it run. a program with no potential for parallelism will not get any parallelism. it will run, but run slow compared to programs designed for parallelism. programs written to exploit parallelism will be programs that bring new approaches to data and state. functional languages provide this today, which is why lots of people think they will be the way forward for multicore. honestly i think you are just bordering on being a troll. why don't you do some reading on this topic before writing more uninformed replies
axod 18y ago
"you're getting beaten over the head by chip designers telling you that your future cpu is going to consist of a (possibly large) array of processing cores with a high-capacity bus connecting them." Sorry, but I don't buy that. We're also moving to a thin client world where we don't actually need that much power on our thin clients. Of course the chip makers are saying that - they want to sell more chips. They have to come up with some other number they can increase.
- crabapple 18y ago
  Sorry, but I don't buy that then you clearly aren't buying new high-end servers for data crunching either, because these are already multicore
  - swombat 18y ago
    As surprising as that may sound, 99% of developers out there are not buying new high-end servers for data crunching, no.
    - crabapple 18y ago
      what is in the cpus of those machines will be in the cpus of all machines. jesus, how much more legit can you get than intel telling you this is coming?
      - 13ren 18y ago
        Itanium
      - d0mine 18y ago
        Intel may try to sell many-core but who wants to buy it?
        crabapple 18y ago
        you. you aren't going to be given the choice, these are coming to a laptop near you...like on your lap
aaronblohowiak 18y ago
"?????? so mongrel comes with its own OS kernel that has better support for multicore than linux and freebsd? wow!! coolzzz!" In fact, quite the opposite. Handling concurrency by having multiple share-nothing processes relies on the OS to handle the scheduling and core assignment. edit: "real" (system) processes.
- crabapple 18y ago
  uh, yeah, i know that. i thought the "coolzzz" would relate my sarcasm
  - aaronblohowiak 18y ago
    Your sarcasm implies that mongrel's scheduling and IPC was inferior to the OS, which is not the case.
anamax 18y ago
> you're getting beaten over the head by chip designers telling you that your future cpu is going to consist of a (possibly large) array of processing cores with a high-capacity bus connecting them. they are telling you this is the only way they can give you higher performance. you had better start believing them because these systems are starting to get delivered now. If your chip designers are telling you that they're building a large array of procesing cores connected with a high-capacity bus, you need to get some new chip designers. If you've got a bus that can actually support a modest number of cores, your cores are too wimpy and should be built with whatever was used for the bus. More likely, you actually have a saturated bus that is the system bottleneck, so your cores are spending most of their time waiting for access. There is no silver bullet. Many problems are bound by bisection bandwidth. The more cores, the worse the problem. You end up devoting proportionally more space and power to communication as you increase the number of processors.
jrockway 18y ago
?????? so mongrel comes with its own OS kernel that has better support for multicore than linux and freebsd? wow!! coolzzz! Hi. You may not have noticed it, but this site is not Reddit. Please try to keep commentary like this to a minimum, where 0 is the minimum. Anyway, please also read the posts you are replying to. They are saying that many applications get concurrency "for free", since the database library handles the concurrency for them. Yes, this can be a bottleneck, but it is a fundamental problem with the notion of locking. If you want maximum performance, don't lock. If you want absolute data integrity, you have to lock. That's a problem. Concurrency should definitely be a part of CS programs, but Intel's thread library isn't the way to do it. CL-STM or Haskell's STM would be much better.

swombat 18y ago

I don't write OS kernels, I write rails application. I don't give a rat's ass about the OS kernel. I don't even give a rat's ass about how Mongrel is programmed. The Rails applications themselves don't need to be altered to run in a multi-core environment. Mongrel naturally scales to as many servers or CPUs as you want to run it on, since there is no interaction between different mongrel instances, all that happens at the database. Let me make that point even clearer: I don't give a shit how the database has been programmed. Someone there has obviously had to think about parallelism, but I don't need to, because I'm not writing a fricken database. Got it?

crabapple 18y ago
I don't write OS kernels, I write rails application. I don't give a rat's ass about the OS kernel then stop spouting off uninformed comments about how processes are scheduled The Rails applications themselves don't need to be altered to run in a multi-core environment. nor do any other program compiled for that architecture. its the OS that schedules processes, not your userland program. the point is, some programs can be written in a way that makes it easier for the OS to exploit multicore. since ruby is not a functional language, my guess is that it would tend to not help the kernel exploit these resources. but obviously in the worst case, a process can run inside one core and never get the advantages of the rest of the chip architecture. this is about exploiting multicore Got it? yes, i get that you know very little about how computers function
- swombat 18y ago
  nor do any other program compiled for that architecture Then none of the people writing those programs need to know or care about parallelism. Therefore, the core message of the article is brain-dead.
  - crabapple 18y ago
    NO. why don't you READ before you reply a program compiled for a multicore CPU will RUN. the question is how OPTIMALLY does it run. a program with no potential for parallelism will not get any parallelism. it will run, but run slow compared to programs designed for parallelism. programs written to exploit parallelism will be programs that bring new approaches to data and state. functional languages provide this today, which is why lots of people think they will be the way forward for multicore. honestly i think you are just bordering on being a troll. why don't you do some reading on this topic before writing more uninformed replies

axod 18y ago

"you're getting beaten over the head by chip designers telling you that your future cpu is going to consist of a (possibly large) array of processing cores with a high-capacity bus connecting them." Sorry, but I don't buy that. We're also moving to a thin client world where we don't actually need that much power on our thin clients. Of course the chip makers are saying that - they want to sell more chips. They have to come up with some other number they can increase.

crabapple 18y ago
Sorry, but I don't buy that then you clearly aren't buying new high-end servers for data crunching either, because these are already multicore
- swombat 18y ago
  As surprising as that may sound, 99% of developers out there are not buying new high-end servers for data crunching, no.
  - crabapple 18y ago
    what is in the cpus of those machines will be in the cpus of all machines. jesus, how much more legit can you get than intel telling you this is coming?
    - 13ren 18y ago
      Itanium
    - d0mine 18y ago
      Intel may try to sell many-core but who wants to buy it?
      - crabapple 18y ago
        you. you aren't going to be given the choice, these are coming to a laptop near you...like on your lap

aaronblohowiak 18y ago

"?????? so mongrel comes with its own OS kernel that has better support for multicore than linux and freebsd? wow!! coolzzz!" In fact, quite the opposite. Handling concurrency by having multiple share-nothing processes relies on the OS to handle the scheduling and core assignment. edit: "real" (system) processes.

crabapple 18y ago
uh, yeah, i know that. i thought the "coolzzz" would relate my sarcasm
- aaronblohowiak 18y ago
  Your sarcasm implies that mongrel's scheduling and IPC was inferior to the OS, which is not the case.

anamax 18y ago

> you're getting beaten over the head by chip designers telling you that your future cpu is going to consist of a (possibly large) array of processing cores with a high-capacity bus connecting them. they are telling you this is the only way they can give you higher performance. you had better start believing them because these systems are starting to get delivered now. If your chip designers are telling you that they're building a large array of procesing cores connected with a high-capacity bus, you need to get some new chip designers. If you've got a bus that can actually support a modest number of cores, your cores are too wimpy and should be built with whatever was used for the bus. More likely, you actually have a saturated bus that is the system bottleneck, so your cores are spending most of their time waiting for access. There is no silver bullet. Many problems are bound by bisection bandwidth. The more cores, the worse the problem. You end up devoting proportionally more space and power to communication as you increase the number of processors.

jrockway 18y ago

?????? so mongrel comes with its own OS kernel that has better support for multicore than linux and freebsd? wow!! coolzzz! Hi. You may not have noticed it, but this site is not Reddit. Please try to keep commentary like this to a minimum, where 0 is the minimum. Anyway, please also read the posts you are replying to. They are saying that many applications get concurrency "for free", since the database library handles the concurrency for them. Yes, this can be a bottleneck, but it is a fundamental problem with the notion of locking. If you want maximum performance, don't lock. If you want absolute data integrity, you have to lock. That's a problem. Concurrency should definitely be a part of CS programs, but Intel's thread library isn't the way to do it. CL-STM or Haskell's STM would be much better.