On Tuesday 11 May 2004 06:47, Jerry Feldman wrote:
I am possibly looking to port a product that runs on Solaris and Windows to Linux. The vendor raised some concerns on G++ and Pthreads. At this time I have few details, and I am just looking into some potential areas that might need tuning. I'm confident that the port itself will be successful, but that the performance might be below expectations. Note that the vendor found that G++ on Solaris was somewhat lacking.They use LWP threads on Solaris. He also mentioned that they used SpartHeap on Windows, which is a commercial version of an optimized malloc. Malloc is always a performance problem in a threaded environment, but that can be mitigated.
My understanding is that NPTL has moved thread support under Linux from mediocre (at best) to seriously good. I does seem that in Linux circles, if you want something improving, you should try to get Ingo Molnar interested in it. ;o) The vendor's concern was probably rightly placed if the application relies on threads to a large extent. On a 2.6 box with an up to date glibc it shouldn't be a problem. This is what I've read, I have no personal experience to pass on. I did, however, have the misfortune to use GCC on Solaris once. It was indeed embarrassingly outclassed by the Sun compiler. Benchmarks were irrelevant - the program was obviously crawling along. I doubt this situation has improved much. However, you're going the other way. GCC still isn't that good on IA32, but it's normally plenty good enough. As long as your application doesn't use libtool and the like, you might want to try the Intel compiler. I played with it once and it generates considerably better code than GCC. Compatibility was the issue for me, but that might not be a problem for you. In general, I doubt whether you'll have any significant problems. Linux is pretty efficient and is more than a match for Windows in most cases. Unlike SPARC/Solaris, if an Intel/Linux box isn't giving good enough performance, the easiest and cheapest way to fix the problem is to upgrade the hardware. Painstaking hand optimisation and tuned library products are kind of pointless when you can get a 25% speed increase for $1000. I guess the economics of that depend on how many workstations you'll be rolling out to. --
eatapple core dump