Date: Thu, 18 Jan 2001 10:07:48 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: kuku@gilberto.physik.rwth-aachen.de (Christoph Kukulies) Cc: freebsd-smp@FreeBSD.ORG Subject: Re: dual CPUs for OpenGL any good? Message-ID: <200101181007.DAA03033@usr08.primenet.com> In-Reply-To: <200101171453.PAA43156@gilberto.physik.rwth-aachen.de> from "Christoph Kukulies" at Jan 17, 2001 03:53:35 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> Sure, this is not a Windows NT group here but I know a lot > of expertise hanging around here: We have an application that runs > under NT and does a lot of OpenGL. CPU load is high. It's a single process, > probably single thread application. I'm wondering if I should invest > in CPUs or in Graphics accelerators (video card). > > Could a monolithic application benefit from multi CPU at all? In general, it depends on where you are spending time, and how you are profiling the application. The best profiling you could do would be to ask MSVC++ to add profiling hooks for all function entries. This would provide non-statistical (i.e. _real_) profiling data that would omit kernel wait time from your profiling data. It's pretty trivial to do this with tiny mods to the gprof code. Note: You only get entry data, so if you want entry and exit data, you have to diddle the stack; this is also pretty trivial, since you can diddle the return address, and the option to add the hooks also turns off tail call optimization (where if the last thing in the function being compiled is a call to another function, MSVC++ will JMP to the function instead of calling it; this works because all functions are assumed to be caller-pops). If you are spending time in user space, then you are pretty much lost, unless your "monolithic" application is pseudo-multithreaded (e.g. it uses timers at the same time it is running to do something "in the background", since timer outcalls actually run on any idle kernel thread in NT and 95/98/2000). > Could driver code run on a different CPU while the other CPU is running for > the application? Generally, this happens whether you want it to or not, but you don't get to lock it to a particular CPU, since it happens in the soft ISR code, which runs on a kernel thread. If your lower level driver is taking interrupts, it's probably locked to a single CPU for handing the hardware interrupts anyway, so your load balancing might be broken and actually work out worse, if you depend on hardware interrupt processing (this is the trick NT uses to use 4 CPUs to beat Linux/FreeBSD file serving). Probably your best bet is a GL-aware accelerator card, that will offload your driver (this is what Alfred recommended), but it won't do you any good if all you are ever doing is waiting for I/O from the card telling you it's done, or it's ready for the next set of commands for you to offload (at that point, it's really time to think about a faster card, or even just a slower card with a much better/more concurrent driver). You should really profile everything, and then eliminate the bottlenecks you can, based on the profiling results. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101181007.DAA03033>