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

[Nick Hill]

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.