[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Tom Edwards wrote: > > I agree, there has been talk of Linux being sluggish recently compared > to Windows (lugradio episodes) Never heard it elsewhere. Experience here is that on the same hardware GNU/Linux based stuff is a lot more responsive, and happily runs a lot more on the same hardware at the same time than say Windows XP. Most likely problem is lots of fancy graphics, and a bad choice of graphics card, or configuration problems. I doubt processor specific binaries are the issue, whilst the general binaries can bloat a little by having code for different CPUs, the only demonstrable and significant gain I've ever seen is when enabling the multimedia options for mplayer, which can allow playback of fullscreen video on low end CPUs which have MPEG extensions. The (3rd party) Debian version use to disable these features, rather than allow them to be selected at run time, I've no idea why they did this. Sure there are always specific edge cases that benefit from hardware specific optimisations, but most routine desktop use is dominated my disk accesses (Linux does caching well), memory management (Linux has three models for this in the 2.6 kernel, perhaps best to make sure your desktops have a kernel optimised for desktop usage), and context switching (Where GNU/Linux has always excelled). Probably just as well, as I don't think anyone would claim GCC turns out code as fast as the Microsoft or Intel C compilers (well it may do recently, but historically it hasn't), yet the fair few percentage points difference from choice of compiler was rarely mentioned by anyone. The same sort of comments might be applied to many other benchmarks, how many Windows v GNU/Linux benchmarks have you read that discussed compiler choice? Some of the chess engine crowd, who care about CPU performance, will test their code with multiple compilers, but the reality is for most applications it isn't a CPU bottleneck that limits performance, and so improvements to the compiler, its flags and optimisations are pretty small beer unless they change something fundamental about how the program accesses disk, memory, or the graphics card. There are of course specific cases that hurt, running GTK based applications on Windows, is a sure way to make them run like a dog, where as the same application in GNOME in GNU/Linux flies because the core libraries are already loaded into memory. Similarly running KDE apps in GNOME, or vice versa, is a recipe for slow start-up times (at least the first time an application is run since booting) for the same reason. -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html