Having eagerly awaited delivery of my new 64bit machine (running XP Pro 64bit, 6Gb Ram and an Nvidia Quadro FX 4600 video card) I’m amazed at the CUDA performance. The first thing I did with the machine was install Manifold Ultimate 64 bit edition.

Following the example in the Manifold help, I loaded one of my own surfaces and performed a transform on it. With Manifold using CUDA facilities on the video card, the process took 33 seconds. With CUDA switched off, the process took just under 20 minutes!!!

(From http://forum.manifold.net/forum/t62427.2 )

To cut the time required for a GIS task from 20 minutes to 33 seconds by using modern hardware at a fraction of the cost of legacy GIS software is revolutionary. Many GIS tasks will see such gains even with a much less expensive card than the Quadro. For example, toss in a 9800 GX2 for a mere $550 and you get 256 processors hammering away at your job.

Getting factors of sixty speed improvements for such low costs is totally revolutionary. If you are buying new computers, make sure you get NVIDIA for your GPU and make sure your system vendor supports NVIDIA. In fact, this is so much bang for the buck you should probably spec out a larger power supply in your computer so you can easily plug in two or three CUDA enabled cards for even more performance. I guess it goes without saying that 64-bits also is the only way to go.

why not use distributed computing

You certainly *could* use distributed computing (which I will refer to as “cluster” computing here) – the main questions being whether doing so is more performant, less costly/convenient, etc.

After all, the “net” is the computer… certainly in the future…

No. The “net” is a communications medium, not the computer. Whether you are linking multiple processors (the real computers) together using local RAM bus bandwidth or whether you are linking multiple processors together using network bandwidth makes a big difference, because networks are vastly slower than local bus bandwidth and because there are practical issues involved in coordinating resources not directly under your control.

From a software perspective, there is not much algorithmic difference between parallelizing a task to run on multiple local processors or parallelizing that task to run on multiple non-local clustered processors. The main differences are the very non-trivial aspects of discovering which resources are available in foreign machines that are much less directly under your control and dealing with the highly asynchronous nature of dispatching part of a task to a remote processor and then collecting and integrating any results when, and if, the dispatched task ever gets serviced. That adds to the cost and complexity of the application as compared to a purely local one.

The main hit to performance is that networks run far, far slower than local parallelization. This is for two reasons:

1. Networks are much slower than processor to RAM bandwidth. WANs are even slower than LANs and because of regulatory bottlenecks are falling even further behind on a proportional basis.

2. The speed of light limits performance as physical distance increases between processors. This is already a factor within architectures seeking multi-teraflop performance.

But setting the above two issues aside, what counts for most people is simple convenience. If you can plug 256 lightning-fast processors into your computer for a mere $550 (as can be done with NVIDIA’s 9800 GX2 board) or 512 processors for about $1100, well, unless your time is worth no more than that of a burger joint’s employee you are simply going to plug in one or two such boards and enjoy the immense power of hundreds of processors locally.

So, yeah, clusters were a great idea in the 1990′s but have become a second or third tier idea in modern times given the rapid progress of vendors like NVIDIA in packing hundreds of processors into local bandwidth for what are nearly free prices.

I think that’s why GIS vendors most advanced in technology (everyone knows we are not talking about ESRI here…) have come out with massively parallel computing using NVIDIA CUDA and are not pushing clusters.

One particular demo that caught my eye regarding nice labeling was:

http://216.103.100.65/mapguide/sftrees/index2.aspx

I can’t tell you about performance, but maybe MG is another option if you’re looking for alternatives.

Our peak IMS performance with Manifold is about 20,000 renders/hour on a 3.2GHz quad core server. Full North American geography simplified to 1:50,000 in the MAP file and more detailed geography loaded in from a PostGIS database at lower zoom levels. We’ve ditched the MapServer object as we need more flexibility, but we’re still using Manifold’s objects as the underlying rendering engine.

Our map servers get between 15,000-30,000 requests per hour during business days. We have 6 machines running 12 instances.

That’s only about 150,000 to 300,000 requests per 10 hour day – more than most sites get but in an absolute frame of reference not all that much. I would not be surprised if you could get all that running on a single dual-socket (eight core) server with, say, 16GB of RAM, running x64 Windows and x64 Manifold and either match or exceed the rendering performance you have today with six machines.

The way to test this without spending or risking a lot of money is to procure a quad-core 64-bit computer with, say, 8GB of RAM… that’s a relatively inexpensive machine that would be just fine as an upgrade for your personal development desktop machine after you’ve finished the test.

Use that machine to get some expertise in Manifold so you can configure your application optimally and then give it a try. Initially, you can do a quick and dirty web site that accesses and displays the big data in a realistic test that avoids any performance killers but which is not totally equipped with all the refinements you’ll eventually add.

If it pans out OK, well, then you can make the bigger jump to a dual socket, big memory server (which tend to cost significantly more than single socket “desktop” machines).

If it doesn’t pan out OK, you will almost certainly discover some new possibilities that you can put into play with future projects that could end up saving you a lot of time and money. Worst case, you just upgraded your personal development machine to be ready for whatever comes down the 64-bit pike.

One point of advice on the machine: get something that can host NVIDIA CUDA cards, ideally with two full-speed sockets so you can do SLI with two CUDA cards. CUDA performance is so intensely addictive and so inexpensive that you’ll never forgive yourself if at the same price you could have sourced a box that later on will let you plug in two full-speed cards but failed to do so.

[Your initial web application almost certainly won't be able to use the CUDA cards but as summer turns into fall the next generation of Mainfold product will quite likely give you some eye-popping performance benefits if you have a CUDA card in the box.]

Serving lots of maps is no problem for us, its the speed in which they render. I’d like more speed but don’t want to drop the quality of the maps we have now.

You’ll have, to some degree, the same issue with Manifold as clearly if you are working with very large, very complex data to provide a lot of detail there is more computation the system must do. But 64-bit operation wins you a lot and even though it is a more complex matter, multicore operation will be a resource you’ll want to utilize too.

It’d be interesting to see screenshots of the rendering options for Manifold. ArcGIS has so many layer rendering options that it makes you dizzy, but it also makes great looking maps (even if they are slow to render.)

Rendering options in Manifold are disperesed among many different features throughout the system. For example, layer opacity is a property of a layer whether it is displayed on the desktop console or through IMS. Likewise zoom ranges, anti-aliasing, various sorts of thematic formatting, label clipping, and what I guess would be hundreds of individual features involved in rendering. Some of these are specific to different data types so they are not in just one part of the user manual. You’d have to visit the drawings, layers, images, surfaces and terrains and so forth chapters.

On the plus side, since these rendering capabilities and options are the same whether you are looking at your map through IMS or through the regular desktop console (akin to using say, ArcView or whatever), that makes it easy to create, edit and see in a WYSIWYG way what will appear in the IMS display.

By the way, everyone reading this who is running 32-bit Windows owes it to their organizations to upgrade their personal machines to 64-bit Windows.

Let me help you justify the expense by assuring you that whatever GIS strategy you end up pursuing, now is the right time to go 64-bit. Prices have dropped, drivers are everywhere, RAM is cheap, new motherboards support the new generation of quad-core processors… it’s a real sweet spot to start getting that hands-on experience upon which your organization will depend when it comes time to move to 64-bits. Rome wasn’t built in a day, and all that.

Considering that 64-bit operation could easily save your organization huge sums of money, now is the time for you to procure a 64-bit box for your desk. Would be irresponsible not to!

I checked out the websites for IMS and they are fairly quick but I wonder why they are so small.

I don’t know what IMS sites you are looking at, but if you are looking at the IMS examples page on the manifold.net web site those are all tutorial examples. The data is deliberately kept small so that the zip files are small and easily downloaded. Plus, you never know what machine a new user is employing to try out sites so it pays to keep examples small in case it is a small, slow machine.

All of the manifold hosted demo sites tend to use smaller frame sizes because some of our visitors connect via slow Internet links (think middle of Africa, etc. ) so they prefer smaller sized web content.

Do you have a website with IMS that increases the extent of the map frame. The

Sure. You can make it whatever size you want. There are lots of sites (see the forum, as well as citations in this thread by contributors) of much larger map frames.

Note that webmasters often prefer smaller sizes for the maps they show for a variety of reasons.

Probably the most frequent is that it takes no thought at all to use a smaller size, like 600 x 400, to assure the display will almost always more easily fit the browser window no matter the size of the monitor/laptop/window than it is to code a variety of sizes to fit different devices.

Probably the next most frequent is that it is almost a law of nature that webmasters, like everyone else, always like more bandwidth than they have purchased. They toss smaller images down the pipe so they can get snappier action for more visitors with a cheaper pipe.

Third is being considerate of users who may have slow Internet connections, a real factor in poorer areas in the US where many folks still use dial-up and absolutely a real factor in many parts of the world where slow Internet connections are the best you can get.

If you have an intranet application over a fast LAN where you know the monitors in use you don’t care about the above, of course, so you’ll likely use larger sizes.

test of quickness is determined by how it handles multitude of large datasets displaying them in an efficient way. How will IMS hold up in a rich vector/raster environment (i.e. 60 detailed GIS layers with high resolution orthophotos (1/2 foot pixel resolution)?

The number of layers or images really doesn’t matter as much as the methodology used.

That depends upon a lot of factors which are set forth in the Performance Tips topic in the user manual. If you want to do complex things with large data on a small machine you will need more expertise to pull that off than someone who is doing simple things with small data on a rocket fast machine. (The usual case with much software).

Let’s consider an example: Manifold gives you very many options with how to store, link and consume images. Choose a fast method (spatial DBMS storage, linked ECW image, etc.) and use the same projection as your map window (so no reprojection on the fly need occur) and it is instantaneous. Choose a slow storage method and force it to reproject on the fly and it will be painfully slow – but those are gross negligence sorts of mistakes that webmasters should not be making.

Likewise, it usually doesn’t pay to try to display 60 layers full of complex data at the same time since the display will be illegible. The more usual situation is that there are 60 layers in the project but only some intelligible subset of them is displayed at any one time. Users (or the application) chooses the layers that are “on” at any given instant, using methods like zoom ranges whereby layers are turned on or off for display automatically as users zoom into or out of the display.

I believe some of the sample sites or those given by users illustrate the use of the above techniques. Zoom ranges, for example, are really easy to use.

With these specifications, can the map window be scaled to fit on a normal 1200×768 or 800×600 resolution map frame and still perform well?

Sure.

Being multicore and 64-bit enabled only helps when the solution can handle these types of specifications eloquently.

More accurately, being multicore and 64-bit are essential technological advantages which help the solution handle those types of specifications eloquently. One of the most important benefits of 64-bit, multicore operation is providing faster rendering performance.

Let’s take an example: many web applications are intrinsically linked to use of DBMS with most sophisticated spatial web applications utilizing spatial DBMS (in fact, now that using spatial DBMS has become effectively free, we see even small users taking advantage of spatial DBMS within the manifold community). It’s a really big deal for performance if you can fetch data from that spatial DBMS using multiple processors to launch multiple threads. If you have eight cores in your server and you run Manifold to link to a georaster stored in Oracle Spatial, Manifold will use all those cores to grab georaster image tiles from the spatial DBMS using multiple threads.

That’s an example where absent multicore performance someone might say “oh, that renders slow… toss another machine at it” but the faster rendering that comes about from multicore performance is not a simple matter of multiple cores each rendering a portion of a small display, it is in speeding up the data access portion of the task, which quite often is indeed the bottleneck. Sure, there are cases where multiple processors can render an image faster when each takes over the rendering of a portion of that image. Manifold does that with image libraries. But I just wanted to use this example to show how multiple processors can improve rendering performance by improving something other than the final rendering task, that is, by improving data access.

If there is a lot going on then likewise you’ll want to have 64-bit operation because then you will not be limited to what in actual practise in 32-bit Windows quite often ends up being a mere 1 GB process space. You’ll want to be able to load up your server with 8, 16, 24 or 32 GB of RAM and actually be able to use that RAM.

In the example given by Phillip, I wouldn’t be surprised that one of the reasons why he needs to use multiple boxes to deal with a relatively small volume of traffic is that each of his boxes is emulating a 32-bit processor running 32-bit Windows. So, instead of being able to use a single contiguous 16 GB space within a single 64-bit box to avoid paging to disk, to manage delays caused by paging caused by the relatively small memory space supported by 32-bit Windows he has to divide up his user services to run on multiple boxes.

That’s just a guess and no doubt there are other factors at play, but going 64-bit often makes a big difference if you have the sorts of complexity issues that make a process just large enough to trigger paging within a 32-bit Windows system. That is a huge deal.

The moment that happens, you are no longer working within the microsecond access times typical of RAM but instead are dealing with the millisecond access times typical of hard disks – a thousand times slower. You don’t have to slow down data access a thousandfold too often to end up making your application dramatically slower than it could be if paging were not in the picture.

By the way, a lot of folks may wrongly think that “oh, I’m concerned about rendering and a 1280 x 1024 frame to render is way under a gigabyte, so that can’t be the case”

That’s not how it works since GIS packages in general have a lot to think about in order to decide exactly what has to be displayed within that 1280 x 1023 frame. So it is not the raw number of bytes for that many pixels, it is the size of the processes involved with working with the data that may or may not be displayed, considering, possibly, the entire size of the data, memory consumed by data access methods, by analytics (as are necessary for things like thematic formatting, deciding how something is to be rendered, visability of what’s visible given on what’s on top or not, etc.) . Also, keep in mind that programs which use Windows will naturally want to leverage a wide variety of Windows facilities and related Microsoft technologies to avoid re-inventing the wheel. It is the most natural thing in the world to include some handy capability without realizing that you’ve just increase the size of your process dramatically to utilize that capability.

[Folks are sometime shocked at the "huge" amount of memory that can be consumed for what seem to be simple things. I'm not bad-mouthing the phenomenon, either, by the way, because human time is far more expensive than RAM. The correct thing to do in modern times is to take advantage of the ability to re-cycle effective, well-debugged code. That's much wiser than re-inventing the wheel to make it fit into what are now obsolete and too-small memory spaces.]

If you are emulating a processor that tops out at only a gigabyte or two you are going to be paging a *lot* more than if you have the seamless ability to use larger RAM. And it must be emphasized that what used to be astronomically expensive, say, 8, 16, 24 or 32 GB of RAM is now very affordable, probably some of the least expensive parts of the web server.