Archive for the ‘Hardware’ Category

Multicore and ArcGIS Explorer

parallelization to the rescue
Can’t make the blades any sharper? Then add more blades (Gillette “Fusion”).

Dave Bouwman has a good writeup on choosing new hardware. It’s interesting that he opted for the dual core instead of quad core.

I’d really be curious to see quad vs. dual core comparisons for ArcGIS Explorer (AGX). Even though AGX has “ArcGIS” in its name, it carries no legacy COM baggage it does not require extensions to be registered with the COM Interop like the rest of the ArcGIS family. Parallel processing seems a lot more doable in the pure .NET custom Task Framework compared to dealing with the COM interop. I’d be interested if anyone has written an asynchronous custom task that leverages multicore. Maybe a spherical version of Life running on a different core?

Then again, as more processing is off-loaded to the GPU, maybe more CPU cores become less relevant. Maybe how tightly integrated the GPU and CPU will become more crucial. AMD’s project (also called “Fusion”) seems to be betting on that with their plans to integrate graphics technology purchased with ATI:

AMD thinks that integrating the GPU will be essential around the end of the decade because so many applications–games and videos, for starters–will want to latch onto the GPU architecture and because the relative performance of a GPU is way beyond the CPU right now.

Remember how a revision of MapObjects morphed into ArcObjects when the value of COM became apparent?

Maybe the same thing could happen with AGX as the value of parallelization becomes apparent.

Google Earth seems to be winning the beauty contest. Maybe I’m missing something, but the Google Earth COM API would be just as difficult to parallelize as ArcObjects. COM is the bottleneck. AGX has no COM requires no COM Interop for extensibility, so wouldn’t it be better?

Advertisements