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

Andy Robinson Andy_J_Robinson at blueyonder.co.uk
Fri May 26 11:56:44 BST 2006


I always find it interesting to both read about and experience the latest
computing power bottleneck. I don’t play games but I do build my own
machines (windows machines admittedly).

Most of what I do (for work and to some extent play) is not intensely
processor hungry. About the only time my current Athlon 64 3000+ hits the
buffers is when JOSM is preparing to displaying the whole of the west
midlands ;-) (or Spyware Doctor is doing something stupid without telling me
first - really must ditch it).

I worked out many moons ago that RAID arrays for disk access was much better
than a single drive and have operated that way ever since. So file access
(or space) if rarely a problem.

So what is my problem? Well it has to be memory. Every time I build a new
system I load it with the sort of memory that will balance the rest of the
system for the budget I have to work with. But each time I need to make an
interim upgrade it's always because of memory issues. Right now it is and I
need to order some more and stick them in (luckily there is still space) but
I find its interesting that its memory issues (and to a lesser extent the
fsb) that so often lead me to the fully upgrade or replacement path rather
than pure speed issues of the processor or other major components.

But hey, I'm self taught on these things and maybe I just don’t build them
right in the first place :-)

Cheers,

Andy

Andy Robinson
Andy_J_Robinson at blueyonder.co.uk 

>-----Original Message-----
>From: dev-bounces at openstreetmap.org [mailto:dev-bounces at openstreetmap.org]
>On Behalf Of Nick Hill
>Sent: 26 May 2006 11:25
>To: Ben Gimpert
>Cc: dev at openstreetmap.org
>Subject: Re: [OSM-dev] Re: osmeditor2 to Java, and a common Java OSM
>clientlibrary
>
>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.
>
>
>_______________________________________________
>dev mailing list
>dev at openstreetmap.org
>http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev







More information about the dev mailing list