Verily I say unto thee, that Matt spake thusly:
> Sinister Midget wrote:
>> On 2009-02-03, chrisv <chrisv@xxxxxxxxxxxxxx> claimed:
>>> nessuno@xxxxxxxxxxxxxxxxxxx wrote:
>>>> "All BlueGene machines run Linux..."
>>> Too bad. They should put Visduh on it, so we could finally see
>>> Visduh run at a decent rate.
>> Are you sure it has the needed horsepower?
> Actually that is interesting. I wonder what compilers they use with
> these (Linux) supercomputers. IME Visual C++ is far better optimized
> than gcc
That may be true of MinGW, but given native compilers and binary
formats, using fully standards-compliant code, stripped output and
dynamic linking, I'd bet that both results would be roughly comparable
in terms of both speed and size. Compiler optimisation has pretty much
hit a plateau, on all platforms, and with most languages (don't know
about C#), beyond which one finds the law of diminishing returns.
Ultimately, the quality of the results is more dependant on the
programmer than the compiler, although icc is still the benchmark.
There was a marked regression in GCC4.x compared to GCC3.x initially,
but AFAICT that has long since been resolved. And of course GNU/Linux
now also has prelinking, which helps considerably.
Frankly I'm more concerned about run-time memory overhead than
compile-time optimisation, and in that regard there are still a few
applications under GNU/Linux which need some work. In particular, I've
noticed KDE4 is a marked improvement over Gnome in that regard (and also
better than KDE3).
My own anecdotal, although long-term, observations are that GNU/Linux is
faster and less bloated than Windows in every regard, but then there are
aspects to this beyond compiler considerations, such as the overall
design concepts of Windows (or lack thereof). Windows' security model,
for example, is a complete shambles, and the manner in which it has been
plastered on to the core is undoubtedly responsible for some of the
bloat and slowness, as is other less useful components such as Protected
Media Path (DRM) and other "features". My gut feeling is that the core
design and development framework concepts of Windows are responsible for
producing a profoundly flawed development paradigm unique to Windows
programmers, and Visual Studio is the tool which perpetuates that flawed
paradigm. This is just a rather long-winded way of saying Windows
programmers need to go back to school, or rather they need to be
"deprogrammed" first, then go back to school.
This is also /one/ of my main concerns about projects like Mono, since
it drags the Windows development paradigm, along with it's respective
developers (and a lot of other undesirable things, like patents) over
from the Vole's side of the fence into Free territory, and "poisons" it.
You can also add that to the list of reasons why cross-platform
development isn't as good for GNU/Linux as you think it is.
> (NTFS is way slow).
NTFS is probably useless for large-scale database application, but then
IMHO so is ext2/3. I'm also not too keen on the rather sinister and
clandestine nature of ADS (Alternate Data Streams), not least of which
because it can harbour some rather nasty rootkits. Its biggest problem
is fragmentation, which also affects ext2/3 to a much smaller degree,
and this undoubtedly contributes to the "slowness" you experience, along
with it's inherent metadata, block, MFT, and security descriptor
overheads, although the latter is somewhat mitigated by the ACL table.
I've never attempted an SELinux benchmark for comparison though.
> I don't expect Vista's cost is much of a deterrent.
It's pretty hard to beat GNU/Linux's $0 license cost.
> MS would probably give them Windows licenses dirt cheap for the
> prestige of running supercomputers.
They'll need to port it first, and AFAICT they lack the motive (profit).
| "Necessity is the plea for every infringement of human freedom. It
| is the argument of tyrants; it is the creed of slaves." ~ William
| Pitt the Younger
Fedora release 8 (Werewolf) on sky, running kernel 188.8.131.52-60.fc8
03:45:33 up 90 days, 11:28, 5 users, load average: 0.01, 0.03, 0.00