Archive for the ‘ArcGIS Explorer’ 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?

Spinning Globes – killer apps for Multicore?

AMD has released a new quad-core processor, dubbed Barcelona, but as with Intels offering, there seems to be a consensus that until software starts leveraging multicore, demand will not take off as hoped.

Seems like geoprocessing would be a natural fit for running on multiple cores. From what I’ve seen though, writing software for multicore is hard. Google bought Peakstream a couple of months ago, a company that makes software tools for multicore development. Here’s a good description. Unlike their acquisition of Sketchup, though, Peakstream has been pulled out of the public eye. To me this means Google thinks Peakstream gives them a competitive advantage. That’s too bad, I really wish there was some sort of free download of PeakStream that would allow me to start playing with multicore, writing tools that extend GE.
hurricane
Maybe Google could even enhance KML with tags indicating how multiprocessors should be exploited. Think of a dynamic 3D weather model described in KML so that load is spread across multiple cores as it runs.

Firing up Google Earth Beta on my dual core doesn’t very evenly tax each core, but I wonder if this will change once Peakstream gets digested. Once that happens, could Google Earth spur demand for multicore?

In looking at AGX, it seems like the custom task framework could be extended to recognize & exploit multicore. ESRI has done a nice job at hiding the threading complexities, seems like the custom tasks framework could be extended so that I can tell a custom task how to handle and choose between multiple cores.

Moving Fast Pushpins

While I was excited to see the OpenGL support in AGX, I didn’t find ESRI’s Custom Drawing sample to be very exciting.

So, I modified it by adding a timer that moves Pushpins around the globe.

The modified code is here.

Build 410 or later required.

Follow

Get every new post delivered to your Inbox.