[mapguide-internals] RE: Vroom Vroom CPU

[Traian Stanev]

A lot of time is also spent rendering and compressing PNGs/JPGs on the output side. This does take very significant CPU power, so you can work around the I/O problem by launching 2 or 3 threads per CPU, so that one thread is doing image compression while the other one is blocked for raster I/O for example. 

I admit though that in many cases you would end up being I/O bound, if the rendering is relatively simple compared to query and size of the source vector/raster data, which probably means such a CPU setup would be overkill unless you have a lot of RAM.

Traian


-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Trevor Wekel
Sent: Wednesday, March 24, 2010 12:51 PM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RE: Vroom Vroom CPU

And once we remove the locks (the GDAL Initiative (wink)), raster will be absolutely brutal on disk.  Even ECW, which I believe is the most miserly from a disk access perspective, can pull 5MB/sec while servicing a single user.

250MB/sec under random read conditions?  SSD or gobs of ram!  

Trevor


-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: March 24, 2010 10:03 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RE: Vroom Vroom CPU


As I said, great for ray tracing, where the whole model is in RAM (or even completely in CPU cache). :) Not so great for anything I/O related.

As for FDO providers -- I have had reasonable success using FDO SQLite from 8 (or even 16) reading threads simultaneously... So it is possible. The big killer will be raster anyway, unless we finally remove the locks from the GDAL provider.

Traian


-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Dave Wilson
Sent: Wednesday, March 24, 2010 11:56 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RE: Vroom Vroom CPU

The problem with 48 cores isn't the number of users, but the disk IO bottleneck you will likely experience if the data isn't being read from either SATA III or SSD drives and even then who knows. And if a provider isn't properly multi-threaded it's all go until that one layer blocks everything.

New fun is on the horizon that is for sure.

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Wednesday, March 24, 2010 8:15 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RE: Vroom Vroom CPU


I would do single-user real time ray-tracing with 48 cores.


Unrelated to MapGuide, I know. :)


Traian


-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Trevor Wekel
Sent: Wednesday, March 24, 2010 8:21 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] Vroom Vroom CPU

http://www.provantage.com/amd-os6172wktcego~7AAMD2EE.htm

The official release should be next week. This chip is also 4 socket capable.  Now what we do with 48 cores...  100, 200, 300 concurrent users?  Maybe more?

Who wants to buy me 4 and a box to go around it?

I will colocate it so we can all use it.  One little condition though - I get punting rights :)

My colo is going to kill me.  You already have 20 amps! Greedy *******!


Regards,
Trevor 

_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals