------art_302638_33321324.1148730621734
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>
> >>>>But the problem is that it doesn't take advantage of these new
> multi-core processor that are now starting to become the standard
> machines being sold (at least for my customers).
>


THAT is absolutely correct, and insightful. Many people have noticed that
raw processor speeds aren't increasing at nearly the same rate they once
did, and all the chip designers are going to some form of multicore
hardware. The most interesting one (to me at least) is the Cell, which
essentially requires a different programming model if you're going to get
the most out of it.

There's a great deal of controversy over this issue, with a lot of people
contending that C compilers bear most of the responsibility for effective
multicore scheduling. Speaking as an application programmer who has also
written a lot of compilers, I'm partially but not fully convinced by this. I
believe that significant changes in programming methodology will be
*required* in the future to write programs with acceptable performance.

Python is IMO quite a bit more sophisticated than Ruby in handling threads.
I don't rate Perl or PHP as serious contenders for thread-hot development
for several reasons. (Besides, they often run inside of Apache processes,
and Apache will naturally take some advantage of the newer hardware because
of its multiprocess nature.)

I come in for a lot of criticism because I don't care for the way many
programmers are trained to use threads. But I think the shortcomings of the
typical approach to threaded programming that is encouraged by languages
like Ruby, Java and even Python will be far more deleterious on the coming
hardware than they are today. Ironically, Java may have an edge because it
has some deployment systems that can partition programs into
indepedently-schedulable pieces. I'd like to see something similar for Ruby
(and have opened a project ("catamount") to do so) but it's still early.

------art_302638_33321324.1148730621734--