Thread safe? Multi Core/64bit benefits?

Topics: SharpMap Project
May 23, 2008 at 3:20 PM
Hey guys,

I plan on using SharpMap to generate a bunch of dynamic maps for display on my website.

Is SharpMap thread safe?
Also, does it take advantage of multi core and/or 64-bit machines?

Thanks,
Matt
Coordinator
May 23, 2008 at 4:13 PM
Hi Matt, By default IIS runs each request in its own single thread, so as long as you are creating an instance of the map class for each request (As opposed to having a static instance) you will be just fine.

v0.9 runs in a single thread,
1.1experimental can run on more than one if you use an async renderer (not really designed for web use though) or if you use an AsyncHandler,
v2 is much more multithreaded and is nearing a beta 2 release but its not quite ready for the bigtime..
hth jd

mattm8305 wrote:
Hey guys,

I plan on using SharpMap to generate a bunch of dynamic maps for display on my website.

Is SharpMap thread safe?
Also, does it take advantage of multi core and/or 64-bit machines?

Thanks,
Matt



May 23, 2008 at 4:56 PM
Hey John,
When you say that v2 is much more multithreaded, do you mean SharpMap will utilize more than one thread to render the images?
Does this take advantage of a multi core machine? what about a 64-bit system?

When my website is under load, I am wondering if SharpMap would run better/faster on a multi core and/or 64-bit system.

Thanks again,
Matt
Coordinator
May 23, 2008 at 5:23 PM
Edited May 23, 2008 at 5:24 PM
Hi Matt, in v2 all dataaccess is async so yes it will utilize more than one thread. I do not think that there is anything in v2 to explicitly use multiple cores any more than the machine would naturally via multi threading , codekaizen can probably fill you in better than me on that. V2 for web is still a way off though..

WRT 64 bits: I run 64 and 32 for dev with no problems - I haven't got any metrics so I cant really say if sharpmap itself improves with 64bits. In production our web servers are currently 32 bit, database servers are 64. The web servers are lower spec and take quite a bit of punishment - probably from GDI. We are planning to replace GDI with an alternative for web rendering but in the short to medium time it is likely to remain as is. 

HTH jd

mattm8305 wrote:
Hey John,
When you say that v2 is much more multithreaded, do you mean SharpMap will utilize more than one thread to render the images?
Does this take advantage of a multi core machine? what about a 64-bit system?

When my website is under load, I am wondering if SharpMap would run better/faster on a multi core and/or 64-bit system.

Thanks again,
Matt



Coordinator
May 24, 2008 at 6:11 AM
Here's my input -

Regarding SharpMap v2, we are looking to allow multithreading in multiple scenarios: data access, index and cache maintenance, and rendering. We're delivering multithreaded data access in Beta 2, it seems, since it will get have the greatest impact. The layered architecture will allow gradual introduction of multithreading where it makes sense. In rendering, this can be a challenge, since multithreading graphical operations often slows them down due to context switching. However, done correctly, it can be sped up if the rendering is complex and the raster output is cached. Since this will require some careful design, it won't be done soon. The rendering is layered now however, so if anyone wants to go for it, replacing the Basic*Renderer2D classes with classes which render on a separate thread.

Regarding multicore, John has it there. It (mostly) all depends on your OS scheduling mechanism.

Regarding 64 bit, my experience is that 64 bit is better. SharpMap doesn't care since it is pure MSIL, and the runtime will create either a 32 or 64 bit process depending on the OS. I've seen both x86 (32-bit) and x64, and the x64 JITter produces better, faster code. I haven't measured carefully, but I'd say SharpMap would be faster. Just look out for the "bitness" of any native DLLs you would be using. In the end, however, it is not as important as the efficiency of the algorithms and implementation of SharpMap, since they will completely swamp any metrics given sufficient data (and there is no shortage of that in the GIS realm). v2.0 still has a good amount of room for performance improvement in the core algorithms.