Choosing a Laptop Computer
Graphics Processor and Memory
The graphics processor (GPU) of a computer can dramatically affect the performance of a program such as Smaart. Depending on the program design, it can be almost as big a factor in program performance as the CPU. Smaart 6, for example, is particularly sensitive to graphics processing power because it does all its real-time charting in OpenGL. Given a decent graphics section, version 6 can actually run significantly faster than SmaartLive 5 runs on the same machine, even though version 6 is doing twice as much work under the hood. This is because OpenGL shifts much of the work of drawing graphs from the main CPU to the video card, greatly relieving one of the primary bottlenecks in previous versions of Smaart – assuming the computer's graphics section is up to the task.
Another important spec' that's easily overlooked is where the video memory lives. Smaart 6 can actually be pretty happy with as little as 16 Megs – 32 or more is better but video RAM these days tends to be measured in hundreds of MBs anyway. So on newer machines, the amount of video memory is unlikely to be an issue for us. But a problem with chipset graphics processors and even some of the name brand (we'd be talking ATI and nVidia) GPUs used in some mid-range systems is that they lack any dedicated video memory. Instead they just use a block of system RAM.
The issue with this approach, GPU performance aside, is that graphics data now has to squeeze through the same pipe as everything else the CPU is doing with memory, rather than having its own pipe directly into the GPU. This might be fine for typical computer programs that spend 99% of their time waiting for someone to tell them to do something, but for a program like Smaart that is constantly chunking large buffers of data around, in addition to spewing real-time graphics out onto the screen dozens of times per second, it's less fine.
Some of this might be somewhat less of an issue with older versions of Smaart and perhaps other systems as well. SmaartLive and its predecessors (and likely some or all of the other Windows-based systems out there) used Windows' native 2-D drawing API to do their real-time charting. More of the work of graphing is done by the main CPU in that case and there's a real limit to how many things a single CPU can do at one time. Graphics hardware could still be an important contributor to performance, but CPU power would probably be king when it came to increasing throughput. It also meant that real performance benefits of better graphics hardware might tend to be a function of how effectively the OS utilized the hardware, more than anything the program did.
