Hello,

I would like to run my own CFD solver programs (3D curvilinear) using PC. I have used these programs on UNIX machines (SGI, SUN, mainframes). I am unsure about which option to follow:

Option 1: Windows NT + Fortran compilers + Windows based plotting packages (I don't know)

Option 2. Linux + Fortran compilers + Tecplot

Any suggestion/ experiences would be greatly appreciated. Thanks

Reaz Hasan

If you already know UNIX, Linux will be easy for you.

The commercial distributions are really easy to install and provide almost everything (xmgrace, gnuplot, g77, gcc...)

You may need an internet link on your PC to install part of what you really need. If you are looking for a really efficient fortran compiler, you may need to buy one. Most of the commercial fortran compiler provide free testing licence. 3 years ago I found the pgf77/pgf90/pgcc package really interesting, it could have change, so you will have to make some internet research to find some benchmarking results.

Sylvain

Hi,

Some years ago I compaired the performance of Windows95 and Linux. I run the same code under both operating systems, I simply changed the partition on one and the same computer. Linux was about five times faster than Windows95. That was the main reason that forced me to develop and use my CFD code under Linux. If you spend some money and bye a good FORTRAN Compiler I believe, you will get happy under Linux.

An other advantage of Linux, is that this operating system is very stable and you can gain some computing power if you run you code without any X11 environment. Under Windows XP/NT, or what any, it is not possible to use this option, I think. Anyway since this time I never used any M$-Produkts any more!

best regards

I. Dotsikas

My benchmark, DVF (now CVF) on window is about 3 times as fast as g77 on linux. My LES code on PII 933Mhz/window 2000 runs as twice as fast on Compaq Workstation 500Mhz (Unix, 64 bit).

Think about that before you make decisions.

>> My benchmark, DVF (now CVF) on window is about 3 times as fast as g77 on linux.

The problem with unreasonably slow gcc under Linux on Intel chips is often failing to align doubles. Depending on the state of you gcc compiler you may even have to add some grotty start up code to fix the problem. A superior alternative is to use the Intel compiler which is currently freely available (but unsupported by Intel). Not surprisingly, it emits noticeably faster code than gcc.

>> My LES code on PII 933Mhz/window 2000 runs as twice as fast on Compaq Workstation 500Mhz (Unix, 64 bit).

This is odd and counter to other peoples results. Why?

>> Think about that before you make decisions.

Hmmm. I think you may have to provide more information to make a convincing case.

>> Linux was about five times faster than Windows95.

Why? What did you do?

>> If you spend some money and bye a good FORTRAN Compiler

Now I believe this is sound advice. FORTRAN requires a good compiler to deliver a speed advantage.

>> An other advantage of Linux, is that this operating system is very stable

I think you will find some disent even within the Linux community. Why has Debian refused to adopt the current 2.4 kernel for what seems like forever?

>> and you can gain some computing power if you run you code without any X11 environment.

I admit that I do not know what computing power means, but apart from reclaiming some memory for some more grid lines what else is there to gain?

Its hard to answer your question without knowing what you are trying to achieve: minimum cost, develop commercial product, another platform to support the work in the lab, etc... Go with whichever platform serves these needs best.

Despite the responses above, a numerical program is going to make almost no calls on the operating system unless it starts swapping (a serious problem). I think you can safely discount the operating system as the direct cause for the big differences in speed reported by others. Certainly the compiler, the processor, etc... is going to make a difference but the most common cause of big differences in my experience is that the performance on one platform has been crippled by a mistake.

I have developed all my CFD codes on PCs using Windows2000 and now XP in Visual C++ 5 and 6. No problems whatsoever.

You are right. The compiler could be the main reason. An other one is that I used as much memory as I could. Windows might have tried to swap. The Linux kernel was compiled and had only what I needed. Not any unnecessary stuff. So a minimum of memory was used. And not to forget: the longer you use Windows the slower gets your system. I can´t say why. It is simply so. I registered the big time difference (10 to 45 Minutes) that the same code needed to be executed. The time was simply stopped with the clock and that was enough for me.

Anyway between the two solutions available I prefered the one that definetly worked. best regards

I. Dotsikas

Sorry for the contrary point of view, but performance completely depends on the code. There is no sound rule except to try it out and see.

For example, the g77 compiler is 10% faster than the portland group compiler on an explicit finite volume density based code that I use. Yet for an implicit pressure based finite volume code that I also work on the portland compiler is 30% faster.

On top of that both my codes run faster in Linux (on the same CPU of course), than in Windows NT/2000.

Neale

A numerical program might not make many specific OS calls but it is still managed by the OS as it executes (memory allocation, processor time, etc..). Linux simply does a much better job at this and that translates into a (albiet slight) performance benefit.

I use 2 completely different single precision CFD codes. g77/portland on Linux and DVF on Windows NT. Both codes perform slightly better under Linux, ~5% or so.

Where you really see a big difference is in parallel scaling. On a 2 cpu machine I get 1.3-1.5 with Windows NT, on Linux I get 1.6-1.8. You can confirm this has nothing to do with parallelisation yourself if you like. First run a serial job and record the execution time. Then, run the same serial job twice, but simultaneously. There is no communication between the processes, so you are just measuring the ability of the OS to maage the processes. What you will find in both OSes (Linux/Windows) is that the jobs run slower when run together. It's slightly faster on Linux.

Neale.

> Some years ago I compaired the performance of
: Windows95 and Linux. I run the same code under both
: operating systems, I simply changed the partition on
: one and the same computer. Linux was about five
: times faster than Windows95.

Mmm, I think that is very atypical, and probably very strongly influenced by the specific compilers used. I've done similar experiments, using g77 in both cases, with the same compiler flags, and got results indicating that there was really no difference in performance between Windows and Linux. I would say that you should choose the software you want use first (compiler, graphics, etc.) and THEN choose between Linux and Windows. Linux is way more stable than Win 95/98, but that is no longer relevant. NT and Win2000 (and XP I believe) are also very stable. A relevant issue with graphics intensive applications is that you may struggle to get Linux drivers for a state of the art high-performance 3D graphics card.

>> I use 2 completely different single precision CFD codes. g77/portland on Linux and DVF on Windows NT. Both codes perform slightly better under Linux, ~5% or so.

Is this down to the OS or the compiler?

>> Where you really see a big difference is in parallel scaling.

There are/were widely reported problems with the scaling of NT on significant numbers of processors. I have no direct experience and do not know the reason but it should be easy enough to google for.

>> On a 2 cpu machine I get 1.3-1.5 with Windows NT, on Linux I get 1.6-1.8.

These figures are low and counter to my experience on Linux - I would suggest a check may well be in order. With this sort of performance you would be running slower on a handful of processors than on one which would be unusual these days. Often one has to change OS level settings/buffer sizes and the like from their single processor defaults in order to run efficiently in parallel.

I agree that the small performance differences between OSes could be compiler dependent. I concede that maybe it's a bad comparison, however, whether it's the compiler or the OS the point is that things were still a bit faster under Linux.

The best performance you can get is 2.0 speedup on a 2 processor machine. The scaling problem has nothing to do with the software you run. It's OS dependent. Do the test I suggested, with almost anything, and you will see what I mean. NT was not really designed to scale past 2 processors, so it's not really a suprise.

Neale.

>> the point is that things were still a bit faster under Linux.

Agreed.

>> The best performance you can get is 2.0 speedup on a 2 processor machine.

It is quite common with modest sized parallel jobs to get a significantly greater than 2.0 speedup when the speed increase from fitting more of 2 half-sized problems into cache is greater than the speed decrease due to the communications overhead.

>> The scaling problem has nothing to do with the software you run. It's OS dependent. Do the test I suggested, with almost anything, and you will see what I mean.

I am not disputing the figures you saw but I am questioning drawing any conclusions from them without doing a "proper" test. Parallel performance figures are affected by a huge range of parameters including the details of your code. For example, if your Linux run is using shared memory and your NT run is defaulting to whatever protocol "sockets" uses on NT (I have no idea how Windows works) because of a configuration issue then you could well see the sorts of figures you are quoting. Similarly, if NT has a minute communication buffer because this is the default setting for a uni-processor. There are a huge range of possibilities for the figures you saw apart from the fundamental design of NT and the fundamental design of Linux.

>> NT was not really designed to scale past 2 processors, so it's not really a suprise.

Hmm. If this were true, wouldn't Microsoft have a pretty hard time selling NT as server software?

>> It is quite common with modest sized parallel jobs to get a significantly greater than 2.0 speedup

Huh. I think you are mistaken. For any real application it just wont happen, unless the entire app somehow fits in cache. I have seen very rare instances of CFD software (including both Fluent and CFX-5) showing superlinear speedup but this is definitely not the norm. If it is I'd be interested in some more examples of this happening.

>> I am not disputing the figures you saw but I am questioning drawing any conclusions from them without doing a "proper" test.

I think you've still missed the point, and I've written enough parallel applications to know what the issues are. Read the test that I originally suggested, carefully, then do it and you will see what I mean. The point was that running two serial jobs at the same time is *slower* than just running the same job once on a dual CPU NT or Linux box. For two serial apps there is no communication with sockets, shared memory or whatever, so the expectation is that you would get a speedup of 2 in this case. You don't. We are simply measuring the ability of the OS to handle scheduling.

>> Hmm. If this were true, wouldn't Microsoft have a pretty hard time selling NT as server software?

Maybe I'm ignorant on NT, but the biggest NT machine I've ever seen had 4 cpus (do they make them bigger?) If NT scaled so well then why don't they use it on big machines i.e., >128 cpus.

Neale.

>> For any real application it just wont happen, unless the entire app somehow fits in cache.

You do not need the entire application in cache but you do need a substantial portion - hence the requirement for modest size. I agree you will not see an affect with large 3D predictions unless the machine has an enormous cache (like some SGIs) but you can, and do, see affects with some benchmarks and modest sized test problems.

>> I think you've still missed the point,...

Possibly. I was assuming the figures you quoted were for a parallel CFD runs and I was referring to those. I could not see how Linux running two serial jobs slightly quicker than NT read across to the parallel figures which, I assumed, would be dominated by interprocess communication.

>> Big NT machines?...

Don't know.