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

[Ben Gimpert]

My personal bottleneck for the past year-or-so has been Internet
bandwidth and CPU.  I don't do all that much in memory, other than the
occasional Photoshop filter.  But hey, that's just me.

		Ben


On Fri, 26 May 06 @11:56am, Andy Robinson wrote:
> 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
> 
> 
> 
> 
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev