James Fee GIS Blog

19 responses so far ↓

• 1 Doug // Sep 19, 2006 at 5:24 pm

  Raise your hand if you are running WinXP-64. No commonplace 64 bit OS on the desktop makes it kind of hard to expect that a 64 bit app would have wide appeal.

  This seems to be something of a problem for lots of apps that would like to go 64 bit (photo and video editing come to mind).

  Hopefully Vista changes all of this. It looks like OEMs are going to actually bundle 64bit versions of vista with x86-64 chips.

• 2 James Fee // Sep 19, 2006 at 6:55 pm

  I’ll be honest, 64 bit is irrelevant for me, but dual core, now that is a different story.

  Heck multi-threaded is a huge issue for me.

• 3 Paul Ramsey // Sep 19, 2006 at 8:12 pm

  Java might finally have an advantage. uDig (Java) has a multi-threaded renderer already and a nice threading API via the Eclipse RCP we use for a workbench/plugin framework. Perhaps this is one of the things that makes Java and .Net “modern” languages?

• 4 Petz // Sep 20, 2006 at 2:08 am

  Wasnt 9.0 supposed to be a complete rewrite of ArcGIS in the first place? And why back then didnt they lay the right foundations for multithreaded support and maybe even 64bit operation ? I mean the main benefit for 64bit is the fact that Windows can effectively manage more than 4GB of Ram. I can image in a year or two that more than 4GB of Ram will be a normality for any serious GIS workstation.

• 5 Matt Eitrem // Sep 20, 2006 at 6:41 am

  I agree with James, the lack of Multi-thredding is a big issue, and is only going to grow in the very near future. Quad processing on the average everyday desktop computer is just around the corner. So, you would expect to see this become the norm much sooner on workstations built for GIS professionals. I know I can’t wait for a dual processor Core2 machine!

• 6 BobC // Sep 20, 2006 at 7:01 am

  Actually, with the default windows settings ArcGIS goes thud between 1.3 and 1.5 GB of virtual memory on my box.. even if the actual memory usage is around 500 MB. Usually happens when I’m working with large raster datasets that are tiled into little bittie chunks.

  A Win32 process is generally limited to 2 GB max address space (This includes MMAP’d files). The rest is used by the OS for page tables and such. There is a kludge that you can include in your boot.ini to increase this process limit to 3 GB, but you also have to flip a bit in the executable file to make it work, and I’ve not tried it. Fiddling with .exe’s often makes license management software go nuts, and I really don’t want to deal with it..

  You can also try relocating .DLL base addresses to leave more contiguous address space, but that’s even more of a pain.

  My usual workaround is to merge the tiles into larger chunks, or try to do that particular bit of processing in gdal or something else with effective memory management.

• 7 Doug // Sep 20, 2006 at 7:02 am

  I think that it is a bit of an overstatement to say that quad processing is almost here. Yes Intel and AMD have quad core CPUs on the way but dual core isn’t that common on the desktop (yet).

  Of course it will all come in due course- i’m writing this post on my wife’s dual mac laptop.

• 8 Adam // Sep 21, 2006 at 8:46 am

  I thought for a second the “GIS X” in your graphic said “OS X.”

  I guess that will never happen though, since ArcGIS wouldn’t be able to crash OS X every 5 minutes like it can with XP…

• 9 Phillip Holmstrand // Sep 22, 2006 at 10:33 am

  yes yes yes James, you are very right! I’d bring up this issue every week or so until ESRI finally gets it.

  Computers are not getting any faster, just more parallel.

  Really what they need to do is support GL or DirectX so hardware acceleration is possible. Then we can finally see graphics at speeds we’d expect to see in 2006, not 1994.

  Or maybe we’ll just wait for somebody else to do it… =o)

• 10 Phillip Holmstrand // Sep 27, 2006 at 11:39 am

  Think there is any chance of getting multi-threading in ArcGIS before these show up?

  http://news.com.com/2100-1006_3-6119618.html?part=rss&tag=6119618&subj=news

• 11 Holger // Sep 29, 2006 at 2:35 am

  64 bit on the Desktop may be a minor(?) part, but it becomes a typical Server environment. Windows 2003 Server comes in 64 bit, Oracle (10gR2) comes in 64 bit, but ArcSDE 9.1 still needs a 32 bit client to connect to the database.

• 12 Very Spatial » GIS and multi-core computers // Oct 3, 2006 at 9:35 pm

  [...] ESRI multi-core and 64-bit processors at James Fee GIS Blog [...]

• 13 Joseph Wallis // Oct 6, 2006 at 7:14 am

  ESRI should concentrate on optimizing their code for SMP. Don’t worry about 64-bit until version 10. however, 9.2 server products need to be recompiled for 64-bit, since it is there where we need access to larger memory space. Dual Core desktops are starting to become mainstream, but writing multithreaded code would benefit a huge portion of people already running Hyperthreaded boxes (those ARE mainstream). Fortunately Windows has done a fairly good job of using the spare cycles on HT boxes that ArcGIS doesn’t take advantage of, but just think if ESRI actually utilized those cycles more efficiently?

• 14 Doug // Oct 6, 2006 at 8:59 am

  Joseph, hyperthreding CPUs are not capable of doing twice the work as normal CPUs. Sadly there is an impression that a HT CPU can do twice as CPU intensive work as a non HT CPU because the task manager shows CPU usage at half on a HT machine when it is chugging away.

  For processor intensive work, a HT machine can actually be a bit slower than a non HT machine… odd but true. In general the performance is the same.

  scroll down to the charts:
  http://www.hardwareanalysis.com/action/printarticle/1557/

  So for x86 the world of multiple threads started with core Duo processors and people who had dual xeon machines. HT wasn’t a proper introduction to multiple CPUs and as such most software developers skipped it and consider it to be nothing more than a passing novelty (assuming they have threads that actually do work).

  Finally for multicore compute intensive tasks I think that you can’t separate the issues of x86-64 and multicore. For example: Do you think that you could effectively run four data hungry threads in 1GB Ram? 2GB Ram? My guess is no and that users probably will need a 1GB Ram for each compute intensive thread unless they want to have four cores thrashing the disk as window’s VM manager tries to fetch disk pages (which would be very bad).

  Anyhow… hardware and software are at a good place to move forward. Time to ditch the limitations of single core and 32bit OS’s. I’m looking forward to computing on quad core machines with 4-8GB of usable RAM.

• 15 James Fee // Oct 6, 2006 at 9:11 am

  “I’m looking forward to computing on quad core machines with 4-8GB of usable RAM.”
  But Doug, will ESRI be there with you?

• 16 Matt Eitrem // Nov 6, 2006 at 8:12 am

  Quad Cores are here!
  http://news.com.com/Intels+quad-core+chip+powerful+but+pricey/2100-1041_3-6132033.html

• 17 meeko // Mar 31, 2007 at 5:37 am

  “I guess we can just use Manifold right? (had to get that in before someone commented about it).”

  thats funny! Though, its also sad when you consider that this company with a $250 GIS seems to have better forward vision than the industry leading GIS vendor.

  Is it me, or is Manifold seeming to run circles around ESRI when it comes to a technological solution, and future predictions of where to bring the product?

  That being said, I think ESRI still has the lead because they are actually being used in organizations to solve real world problems, and don’t have the speed problems that Manifold has

• 18 Jim // Jan 17, 2008 at 7:26 am

  The longer I work in an ESRI shop, the more I despise those idiots. For what we pay in software and maintenance fees, their products should be a heck of a lot more stable and a lot more progressive. I hope they cease to exist in the near future. Of course, I’d then have to adapt my skill set, as I’ve been hitched to nothing but this ESRI train for far too long.

• 19 Multi-cores and 64-bit GIS // Mar 12, 2008 at 1:35 pm

  [...] hit on this discussion before and with the Developer Summit coming up maybe it is a good time to think about the direction [...]

Leave a Comment