logo       
Google Custom Search
    AddThis Social Bookmark Button
-->

Re: [OSM-dev] Re: osmeditor2 to Java, and a common Java OSM client library: msg#00150

Subject: Re: [OSM-dev] Re: osmeditor2 to Java, and a common Java OSM client library
Ben Gimpert wrote:
Hi Nick,

(This is a refreshing take on the "my favourite language" holy war.
Thanks for the thoughtful discussion!)

I agree. I think an airing of deep issues is great, and shouldn't be seen as disagreeable.


On Thu, 25 May 06 @08:38pm, Nick Hill wrote:

Ben Gimpert wrote:

I can think of an example where the selection of Ruby wouldn't be
suitable. Say there is a need to serve data based on mathenmatical
transformations. Say that transformation is similar to a mandelbrot
function. Let's say we need to serve 250 such services per second.

Let's say the average data served took 11.2M CPU cycles to process
when written in C and 9Bn CPU cycles when written in Ruby (tests bear
this relationship out as being realistic for a mandelbrot type
function).

We could service all requests with one 3Ghz CPU if written in C. How
many CPUs would we need if written in Ruby?


I don't care.  And more importantly, I don't think *we* should care.

There's an important distinction to be made here between real-time
systems and what might be called "normal" software.  The real-time
software flying a passenger jet has firm requirements on performance,
and thus an entire software development culture supporting the writing
of such software.  (Eight zillion testers per developer, intense
idiomatic code review, everything in C, etc.)

On the other hand, we at OSM are writing software that can pragmatically
expect to have plenty of hardware to cope with the "hit" of any high
level language -- as long as the algorithms are good (see above).
Something might take the equivalent of 3 million quid's worth of CPU to
calculate today, but it'll take 10 pence tomorrow.  Hooray for Moore's
Law.

Ruby appears to have a very valuable, strong point; it's clean architecture and the effect it has on coding encourages maintainable code. HOWEVER, please forget the 3 million quid's worth and 10p. Actually calculate values which can be applied on a knowable time frame.

My 3 year old athlon XP 2200+ cost £46 and performs like a 2.3Ghz P4. A dual core P4 2.66 today costs £85.

Actual:
Performance: Twice
Cost:Twice
Dissipation: 1.5-2x.

If the historical implications of moore's law were holding today over 3 year time frame:
Performance: 4x
Price Same
Dissipation:Same

I am not suggesting that moore's law need stall, or that we are now at physical limits. However, the evidence could lead to that conclusion. This is just as likely to be the levelling of demand for faster processors on the desktop. There is no new money in faster processors for the desktop. The new raw processing money will come from charging premium prices for applications which need concentrated processing power.

From these figures, if performing a mandelbrot-type task in C at a given rate cost £300 today, in 3 years time with Ruby will cost £120,000. (In actual terms, this could be considered a price for every 6 months considering HVAC+power+space. With projected fuel scarcity, the figures for 3 years time may be higher.).

Processor manufacturers will continue to introduce new instructions and features to enhance those areas where the use of desktop computers still comes up against limits, such as games. Intel have made such an announcement. It is possible, but by no means certain that we can make use of these instructions.


<Prev in Thread] Current Thread [Next in Thread>