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?


2 comments so far

  1. Steven Citron-Pousty on

    AGX definitely had COM, and unless they did a total rewrite in the last year then it is still there. They have put .NET wrappers around it but there are definitely parts that are ArcObjects underneath. It is just a stripped down AO so you only get what you need for a globe viewer. Perhaps there is some OpenGL work there as well but there is still COM in the mix.

  2. Kirk on

    Hi Steven –
    Yes, you are certainly correct … in looking at the bin folder I see a lot of familiar (COM) dlls. Still, when I create a custom Task, I don’t have to register with the COM the Interop as I do with other ArcGIS applications. To me this implies the core AGX application is .NET (no?) ESRI.ArcGIS.E2API.dll has no COM dependencies that I can see. So do all the threading restrictions listed in EDN apply to AGX or just to the IApplication based apps?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: