Greetings Fortran Fans,



I am pleasantly surprised to find an active Fortran group on the net. This 
is my first post to this group and I am looking for some help regarding 
multithreading on multicore processors.



First some background is in order. I have an ancient version of DEC/HP 
Fortran, which has been used exclusively over the years to dabble in a 
floating-point simulation. However, I stopped development about 10 years ago 
when single processors sort of reached their maximum speed. At that time I 
thought I would try creating a multithreaded application and try the 
simulation on an SMP machine but since these systems were expensive, I 
tabled that development. Now, multicore chips are the rage and with the 
release of Intel's quad core chip a few months back, I have been thinking of 
updating my simulation to use these multicore systems. Keep in mind that I 
am a complete hack at programming and my skills if any are old. This is 
something I do for fun not work, so probably buying a new Fortran 
development package is beyond my means.



So I drag out my ancient Developers Studio and load it up on my relatively 
new dual core (AMD) WIN XP system. My old simulation code recompiles and 
runs just the same as it always did and since it is a single threaded 
application, it of course only uses on core at a time. I know that in the 
90's when I first had this compiler, there were sample applications that 
created multithreaded applications and I am pretty sure I tested these on a 
dual processor machine running Win NT. When I tested the sample application 
back then, it did use both processors, running 100% busy as one might 
expect.



I recompile this same multithreaded application and run it on my current 
machine. I load it up with about 50 threads but my twin cores run only 50% 
busy. This indicates to me that while the OS sees these threads as unique, 
they are not being utilized (not sure what the right term is) the same way 
as on the older SMP WIN NT systems. I did try this application on an older 
dual processor system running Win 2K and the result was the same on the new 
dual core system.



So my long winded question: Is there something fundamentally different in 
the way threads are treated now and is there a easy way, like a compile or 
link option (not bloody likely I suspect) open to me so that I can utilize 
both processing cores efficiently?



Thanks in advance,

Rod 

> I recompile this same multithreaded application and run it on my current 
> machine. I load it up with about 50 threads but my twin cores run only 50% 
> busy. This indicates to me that while the OS sees these threads as unique, 
> they are not being utilized (not sure what the right term is) the same way 
> as on the older SMP WIN NT systems. I did try this application on an older 
> dual processor system running Win 2K and the result was the same on the new 
> dual core system.
> 
> 
> 
> So my long winded question: Is there something fundamentally different in 
> the way threads are treated now and is there a easy way, like a compile or 
> link option (not bloody likely I suspect) open to me so that I can utilize 
> both processing cores efficiently?
> 
If your implicit ground rule is Windows only, free compilers only, your 
options
are few.  The easy way to meet your goals is with OpenMP.  gfortran 4.2 
and 4.3 incorporate OpenMP, but not on Windows, so you
would need linux, if you want free OpenMP, as gnu OpenMP is not 
implemented on Windows.
OpenMP is built on the usual threading capabilities of the OS (Windows 
threads, or pthreads for linux), so the basic capability is there even 
without an OpenMP compiler.  Threads generally have to be managed in C.
Current commercial Fortran compilers incorporate OpenMP and (for the 
right combinations of compiler and CPU brands) built-in methods for 
pinning threads to processors.

Thanks for your input Tim. Linux/Unix is not really a viable option for me 
for a couple of reasons. Linux seems to be too platform dependent, is way 
too arcane to administer and is (arguably) computationally slow compared to 
Windows. While the lure of cheap/free OS and tools is compelling, I have 
drunk way too much Microsoft Kool-Aid to switch systems.

I was hoping some of the gurus on this forum would be familiar with my 
current compiler and have a compiler option which would magically solve my 
problem. I did do some checking and the Intel Fortran can be purchased 
relatively inexpensively but I need the MS developers package with C++ to 
install this which equates to more expense. (I am not sure what C++ has to 
do with anything related to Fortran though.) I have to decide if my little 
hobby is worth the cost and effort.

Thanks again!
Rod
"Tim Prince" <tprince@nospamcomputer.org> wrote in message 
news:QK5qh.34044$Gr2.1427@newssvr21.news.prodigy.net...
>
>> I recompile this same multithreaded application and run it on my current 
>> machine. I load it up with about 50 threads but my twin cores run only 
>> 50% busy. This indicates to me that while the OS sees these threads as 
>> unique, they are not being utilized (not sure what the right term is) the 
>> same way as on the older SMP WIN NT systems. I did try this application 
>> on an older dual processor system running Win 2K and the result was the 
>> same on the new dual core system.
>>
>>
>>
>> So my long winded question: Is there something fundamentally different in 
>> the way threads are treated now and is there a easy way, like a compile 
>> or link option (not bloody likely I suspect) open to me so that I can 
>> utilize both processing cores efficiently?
>>
> If your implicit ground rule is Windows only, free compilers only, your 
> options
> are few.  The easy way to meet your goals is with OpenMP.  gfortran 4.2 
> and 4.3 incorporate OpenMP, but not on Windows, so you
> would need linux, if you want free OpenMP, as gnu OpenMP is not 
> implemented on Windows.
> OpenMP is built on the usual threading capabilities of the OS (Windows 
> threads, or pthreads for linux), so the basic capability is there even 
> without an OpenMP compiler.  Threads generally have to be managed in C.
> Current commercial Fortran compilers incorporate OpenMP and (for the right 
> combinations of compiler and CPU brands) built-in methods for pinning 
> threads to processors. 

"Nobody" wrote:
> Thanks for your input Tim. Linux/Unix is not really a viable option for me 
> for a couple of reasons. Linux seems to be too platform dependent, is way 
> too arcane to administer and is (arguably) computationally slow compared to 
> Windows. While the lure of cheap/free OS and tools is compelling, I have 
> drunk way too much Microsoft Kool-Aid to switch systems.

Why switch?  I'm currently running GFortran on Linux in a VMWare virtual 
machine on my Windows box.  Best of both worlds.

It's no more arcane than Windows to administer -- but, honestly, that 
amounts to "pretty arcane if you aren't familiar with it, and pretty 
simple if you are" for both systems, I suppose.  You can download a 
virtual machine with Debian Linux preinstalled on it, though, which is 
what I did; that takes a lot of the effort out of the setup.  (And it's 
a lot easier to set up and administer a single-use virtual machine than 
a real machine that you're using for a primary desktop.)

Do you have any cites with regards to Linux being computationally slow 
compared to Windows?  I've never seen anything that suggested there was 
a notable difference, and the number of people doing substantial number 
crunching on Linux machines would tend to suggest otherwise.

> I was hoping some of the gurus on this forum would be familiar with my 
> current compiler and have a compiler option which would magically solve my 
> problem. I did do some checking and the Intel Fortran can be purchased 
> relatively inexpensively but I need the MS developers package with C++ to 
> install this which equates to more expense. (I am not sure what C++ has to 
> do with anything related to Fortran though.) I have to decide if my little 
> hobby is worth the cost and effort.

What Intel's Fortran uses from the MS developers package is things like 
the linker and the GUI.  (You're right that C++ has nothing to do with 
Fortran, but the package is considerably more than just C++....)

I believe that the current versions of Intel's Fortran still work with 
MS's free command-line version of its compilers, which include the 
linkers and things but no GUI.  Of course, then you just get a 
command-line Fortran compiler, which is fine if that's what you want, 
but can be a bit of a shock to people used to working with Windows 
stuff.  :)

- Brooks



-- 
The "bmoses-nospam" address is valid; no unmunging needed.

In article <z82dnd4ubozGYzbYnZ2dnUVZ_tqnnZ2d@comcast.com>,
Nobody <nobody@nowhere.net> wrote:

> and is (arguably) computationally slow compared to 
> Windows.

You'd be hard pressed to find anyone who argues that based on fact,
because as far as anyone can tell, for straight computation they're
the same.

But it's certainly the case that if you're comfortable admin-ing a
Windows box and not a Linux box, that "installing a free Linux" is
going to be expensive for you.

-- greg

Nobody wrote:
>  Linux/Unix is not really a viable option for me 
> for a couple of reasons. Linux seems to be too platform dependent, is way 
> too arcane to administer and is (arguably) computationally slow compared to 
> Windows. 
>  I did do some checking and the Intel Fortran can be purchased
> relatively inexpensively but I need the MS developers package with C++ to 
> install this which equates to more expense. 
Microsoft appears to be opening up agreements with Fortran compiler 
vendors to permit offerings with GUI, linker, and libraries, resembling 
Compaq Fortran, sometime this year.  I suppose it may increase price.
With nearly annual new major Windows versions, and linux running across 
a wide variety of platforms, it's difficult to understand your argument 
about platform dependence.
For arcane, I don't know what beats the Windows scheme of having to 
remember the double ctrl-alt-delete sequence to log in with your 
administrator password, when you inadvertently don't log in the last few 
days before your user password expires.  If you have bought weeks of 
training in Windows administration, of course you may not want to let it 
go to waste by using an alternative which has a lot in common with what 
we have used for 20 years.
I don't know how Windows could be considered "computationally slow" 
compared to linux.  We are still struggling to find a working Windows 
InfiniBand. OpenMP implementations which deal with thread placement on 
Windows have only recently become widespread, and not in the open 
source.  Each time, no magic bullet, more software updates to buy.

Greg Lindahl wrote:
> In article <z82dnd4ubozGYzbYnZ2dnUVZ_tqnnZ2d@comcast.com>,
> Nobody <nobody@nowhere.net> wrote:

>>and is (arguably) computationally slow compared to 
>>Windows.

> You'd be hard pressed to find anyone who argues that based on fact,
> because as far as anyone can tell, for straight computation they're
> the same.

For code from the same compiler, it should be the same.  For system
calls (mostly I/O) I usually believe Windows is slower, but some
may disagree.

> But it's certainly the case that if you're comfortable admin-ing a
> Windows box and not a Linux box, that "installing a free Linux" is
> going to be expensive for you.

I believe it is a Microsoft rumor that Windows is easier to administer.
But yes, whichever one you are more used to will be easier.

-- glen

Nobody wrote:
> I was hoping some of the gurus on this forum would be familiar with
my
> current compiler and have a compiler option which would magically
> solve my problem.

The simplest approach, guaranteed to work, is to divide your problem
into two parts that can be executed separately and independently, and
then to do the computations via two starts of the same (or different)
executables, so they run at the same time. No special compiler options
needed.

Hi

I have an installation of Intel Fortran v9.something on my Windows XP
PC.  I also have the free download (at least, I believe it was free to
download) of MS Visual Studio .NET 2003 which I use as the front-end to
the compiler, linker etc.  The integration is fine.  When I set up my
DE Intel Fortran did not play nicely with VS 2005 and I've had no
reason to change the GUI in the last year or so.

As to C++'s relationship to Fortran -- well, I get involved in a fair
bit of multi-language system building for my sins.  But then I'm paid
to endure that sort of pain.

Regards
Mark Westwood

On 15 Jan, 22:21, "Nobody" <nob...@nowhere.net> wrote:
> Thanks for your input Tim. Linux/Unix is not really a viable option for me
> for a couple of reasons. Linux seems to be too platform dependent, is way
> too arcane to administer and is (arguably) computationally slow compared to
> Windows. While the lure of cheap/free OS and tools is compelling, I have
> drunk way too much Microsoft Kool-Aid to switch systems.
>
> I was hoping some of the gurus on this forum would be familiar with my
> current compiler and have a compiler option which would magically solve my
> problem. I did do some checking and the Intel Fortran can be purchased
> relatively inexpensively but I need the MS developers package with C++ to
> install this which equates to more expense. (I am not sure what C++ has to
> do with anything related to Fortran though.) I have to decide if my little
> hobby is worth the cost and effort.
>
> Thanks again!
> Rod"Tim Prince" <tpri...@nospamcomputer.org> wrote in messagenews:QK5qh.34044$Gr2.1427@newssvr21.news.prodigy.net...
>
>
>
> >> I recompile this same multithreaded application and run it on my current
> >> machine. I load it up with about 50 threads but my twin cores run only
> >> 50% busy. This indicates to me that while the OS sees these threads as
> >> unique, they are not being utilized (not sure what the right term is) the
> >> same way as on the older SMP WIN NT systems. I did try this application
> >> on an older dual processor system running Win 2K and the result was the
> >> same on the new dual core system.
>
> >> So my long winded question: Is there something fundamentally different in
> >> the way threads are treated now and is there a easy way, like a compile
> >> or link option (not bloody likely I suspect) open to me so that I can
> >> utilize both processing cores efficiently?
>
> > If your implicit ground rule is Windows only, free compilers only, your
> > options
> > are few.  The easy way to meet your goals is with OpenMP.  gfortran 4.2
> > and 4.3 incorporate OpenMP, but not on Windows, so you
> > would need linux, if you want free OpenMP, as gnu OpenMP is not
> > implemented on Windows.
> > OpenMP is built on the usual threading capabilities of the OS (Windows
> > threads, or pthreads for linux), so the basic capability is there even
> > without an OpenMP compiler.  Threads generally have to be managed in C.
> > Current commercial Fortran compilers incorporate OpenMP and (for the right
> > combinations of compiler and CPU brands) built-in methods for pinning
> > threads to processors.

David Jones wrote:
> Nobody wrote:
> 
>>I was hoping some of the gurus on this forum would be familiar with
> 
> my
> 
>>current compiler and have a compiler option which would magically
>>solve my problem.
> 
> 
> The simplest approach, guaranteed to work, is to divide your problem
> into two parts that can be executed separately and independently, and
> then to do the computations via two starts of the same (or different)
> executables, so they run at the same time. No special compiler options
> needed.
> 
> 
Perhaps dumb question from a scientific user (not a programmer): How 
much of the second core will be tied up anyway with system housekeeping 
chores?  I was pleasantly surprised to find that my old fortran code 
runs appreciably faster on a new dual-core laptop than I would have 
expected from clock speed alone, and concluded that it must simply be 
dumping all the Windows background garbage onto the second core without 
any intervention required on my part.

Brooks Moses wrote:
> 
> 
> Why switch?  I'm currently running GFortran on Linux in a VMWare virtual 
> machine on my Windows box.  Best of both worlds.
> 
Sounds interesting, but the VMWare web site tells nothing about costs or 
capabilities unless you first register.  Wikipedia was more informative 
but still gave no idea what it costs to get into that game. Some of the 
VMware software seems to be free, but are the free tools sufficient to 
compile and run gfortran or g95?

Charles Russell wrote:
> David Jones wrote:
>> Nobody wrote:
>>
>>> I was hoping some of the gurus on this forum would be familiar
with
>>
>> my
>>
>>> current compiler and have a compiler option which would magically
>>> solve my problem.
>>
>>
>> The simplest approach, guaranteed to work, is to divide your
problem
>> into two parts that can be executed separately and independently,
and
>> then to do the computations via two starts of the same (or
different)
>> executables, so they run at the same time. No special compiler
>> options needed.
>>
>>
> Perhaps dumb question from a scientific user (not a programmer): How
> much of the second core will be tied up anyway with system
> housekeeping chores?  I was pleasantly surprised to find that my old
> fortran code runs appreciably faster on a new dual-core laptop than
I
> would have expected from clock speed alone, and concluded that it
> must simply be dumping all the Windows background garbage onto the
> second core without any intervention required on my part.

I have typically less than 3% CPU usage when no applications are
running, going up to 6% briefly if the mouse is moved. You would have
less base usage on a non-networked Computer. See the Processor tab of
Task Manager. By default on a multiprocessor/ multicore system the
cores aren't assigned to a particular processor so that it turns out
that each is given roughly equal usage ... each would have just over
50% usage with a single mainly-single-thread-application. You should
be able to see usage for both cores separately in Task Manager.

Thanks Brooks,

The virtual machine idea is an interesting approach but I suspect not 
efficient for the the simulation I am working on where computational speed 
is the most important thing.

I guess the Linus being slow to Windows comes from empirical evidence I have 
seen over the years and no real hard testing. The one recent test I have 
done is using DSL (Damn Small Linux) on an older machine. Since I also have 
few systems running Einstein@Home, the DSL system benchmark was about 30% 
slower than the same machine running Win 2K. In the old days, I compiled my 
simulation on a Sun Unix system and it ran significantly slower than I was 
expecting given its benchmarks at the time. I guess it has always been my 
impression that Unix/Linux systems were not particularly efficient at 
floating point calculations.

Rod

"Brooks Moses" <bmoses-nospam@cits1.stanford.edu> wrote in message 
news:45AC23B4.2070207@cits1.stanford.edu...
> "Nobody" wrote:
>> Thanks for your input Tim. Linux/Unix is not really a viable option for 
>> me for a couple of reasons. Linux seems to be too platform dependent, is 
>> way too arcane to administer and is (arguably) computationally slow 
>> compared to Windows. While the lure of cheap/free OS and tools is 
>> compelling, I have drunk way too much Microsoft Kool-Aid to switch 
>> systems.
>
> Why switch?  I'm currently running GFortran on Linux in a VMWare virtual 
> machine on my Windows box.  Best of both worlds.
>
> It's no more arcane than Windows to administer -- but, honestly, that 
> amounts to "pretty arcane if you aren't familiar with it, and pretty 
> simple if you are" for both systems, I suppose.  You can download a 
> virtual machine with Debian Linux preinstalled on it, though, which is 
> what I did; that takes a lot of the effort out of the setup.  (And it's a 
> lot easier to set up and administer a single-use virtual machine than a 
> real machine that you're using for a primary desktop.)
>
> Do you have any cites with regards to Linux being computationally slow 
> compared to Windows?  I've never seen anything that suggested there was a 
> notable difference, and the number of people doing substantial number 
> crunching on Linux machines would tend to suggest otherwise.
>
>> I was hoping some of the gurus on this forum would be familiar with my 
>> current compiler and have a compiler option which would magically solve 
>> my problem. I did do some checking and the Intel Fortran can be purchased 
>> relatively inexpensively but I need the MS developers package with C++ to 
>> install this which equates to more expense. (I am not sure what C++ has 
>> to do with anything related to Fortran though.) I have to decide if my 
>> little hobby is worth the cost and effort.
>
> What Intel's Fortran uses from the MS developers package is things like 
> the linker and the GUI.  (You're right that C++ has nothing to do with 
> Fortran, but the package is considerably more than just C++....)
>
> I believe that the current versions of Intel's Fortran still work with 
> MS's free command-line version of its compilers, which include the linkers 
> and things but no GUI.  Of course, then you just get a command-line 
> Fortran compiler, which is fine if that's what you want, but can be a bit 
> of a shock to people used to working with Windows stuff.  :)
>
> - Brooks
>
>
>
> -- 
> The "bmoses-nospam" address is valid; no unmunging needed. 

Greg,

Yes, I have played with Linux installations and I found them to be very 
problematic just for the installation. Once, installed, I have no real idea 
what to do to proceed (and I administered a Unix system in in the late '80s 
so I am not a complete noob-just mostly). I have way too many tools that I 
am comfortable with in the MS space and changing over would be a huge 
investment in time and probably money. Also, creating the application for 
Windows gives me a portable solution that will run on most platforms that I 
am not sure is true for Linux

Thanks,
Rod

"Greg Lindahl" <lindahl@pbm.com> wrote in message 
news:45ac34c0$1@news.meer.net...
> In article <z82dnd4ubozGYzbYnZ2dnUVZ_tqnnZ2d@comcast.com>,
> Nobody <nobody@nowhere.net> wrote:
>
>> and is (arguably) computationally slow compared to
>> Windows.
>
> You'd be hard pressed to find anyone who argues that based on fact,
> because as far as anyone can tell, for straight computation they're
> the same.
>
> But it's certainly the case that if you're comfortable admin-ing a
> Windows box and not a Linux box, that "installing a free Linux" is
> going to be expensive for you.
>
> -- greg
>
> 

Hi Mark,

Thanks. Where did you get your free download? From Microsoft directly? I do 
have a copy of the developers studio with my current package. It is labeled 
Developers Studio '97. Wow, ten years old already, so you can tell how much 
I have used this package in the last few years. I guess this package is too 
old to use with the current Intel compiler.

It also makes me nervous the as an Intel product, it will work fine for 
applications on Intel CPUs but what about AMD CPUs. Does anyone have 
experience with AMD processors using an Intel compiler?

Thanks again.

Rod

"Mark Westwood" <markc.westwood@gmail.com> wrote in message 
news:1168966776.154854.34750@s34g2000cwa.googlegroups.com...
> Hi
>
> I have an installation of Intel Fortran v9.something on my Windows XP
> PC.  I also have the free download (at least, I believe it was free to
> download) of MS Visual Studio .NET 2003 which I use as the front-end to
> the compiler, linker etc.  The integration is fine.  When I set up my
> DE Intel Fortran did not play nicely with VS 2005 and I've had no
> reason to change the GUI in the last year or so.
>
> As to C++'s relationship to Fortran -- well, I get involved in a fair
> bit of multi-language system building for my sins.  But then I'm paid
> to endure that sort of pain.
>
> Regards
> Mark Westwood
>
> On 15 Jan, 22:21, "Nobody" <nob...@nowhere.net> wrote:
>> Thanks for your input Tim. Linux/Unix is not really a viable option for 
>> me
>> for a couple of reasons. Linux seems to be too platform dependent, is way
>> too arcane to administer and is (arguably) computationally slow compared 
>> to
>> Windows. While the lure of cheap/free OS and tools is compelling, I have
>> drunk way too much Microsoft Kool-Aid to switch systems.
>>
>> I was hoping some of the gurus on this forum would be familiar with my
>> current compiler and have a compiler option which would magically solve 
>> my
>> problem. I did do some checking and the Intel Fortran can be purchased
>> relatively inexpensively but I need the MS developers package with C++ to
>> install this which equates to more expense. (I am not sure what C++ has 
>> to
>> do with anything related to Fortran though.) I have to decide if my 
>> little
>> hobby is worth the cost and effort.
>>
>> Thanks again!
>> Rod"Tim Prince" <tpri...@nospamcomputer.org> wrote in 
>> messagenews:QK5qh.34044$Gr2.1427@newssvr21.news.prodigy.net...
>>
>>
>>
>> >> I recompile this same multithreaded application and run it on my 
>> >> current
>> >> machine. I load it up with about 50 threads but my twin cores run only
>> >> 50% busy. This indicates to me that while the OS sees these threads as
>> >> unique, they are not being utilized (not sure what the right term is) 
>> >> the
>> >> same way as on the older SMP WIN NT systems. I did try this 
>> >> application
>> >> on an older dual processor system running Win 2K and the result was 
>> >> the
>> >> same on the new dual core system.
>>
>> >> So my long winded question: Is there something fundamentally different 
>> >> in
>> >> the way threads are treated now and is there a easy way, like a 
>> >> compile
>> >> or link option (not bloody likely I suspect) open to me so that I can
>> >> utilize both processing cores efficiently?
>>
>> > If your implicit ground rule is Windows only, free compilers only, your
>> > options
>> > are few.  The easy way to meet your goals is with OpenMP.  gfortran 4.2
>> > and 4.3 incorporate OpenMP, but not on Windows, so you
>> > would need linux, if you want free OpenMP, as gnu OpenMP is not
>> > implemented on Windows.
>> > OpenMP is built on the usual threading capabilities of the OS (Windows
>> > threads, or pthreads for linux), so the basic capability is there even
>> > without an OpenMP compiler.  Threads generally have to be managed in C.
>> > Current commercial Fortran compilers incorporate OpenMP and (for the 
>> > right
>> > combinations of compiler and CPU brands) built-in methods for pinning
>> > threads to processors.
> 

David,

Unfortunately, my problem doesn't separate this way. I did think about this 
for a time and wondered if a distributed approach would work. However, I 
decided that for this class of problem, it would be very inefficient. What I 
think I really need (and of course I am no expert in this either) is to run 
this application on a single box where the code can be efficiently divided 
between processor cores and were memory can be shared quickly.
Good idea though.

Rod

"David Jones" <dajxxx@ceh.ac.uk> wrote in message 
news:45aca483$1@news.nwl.ac.uk...
> Nobody wrote:
>> I was hoping some of the gurus on this forum would be familiar with
> my
>> current compiler and have a compiler option which would magically
>> solve my problem.
>
> The simplest approach, guaranteed to work, is to divide your problem
> into two parts that can be executed separately and independently, and
> then to do the computations via two starts of the same (or different)
> executables, so they run at the same time. No special compiler options
> needed.
>
> 

Grogley <grogley@!nospam!yahoo.com> wrote:

> I guess it has always been my 
> impression that Unix/Linux systems were not particularly efficient at
> floating point calculations.

That makes very little sense, insomuch as floating point calculation
generally has very little to do with the operating system.

My general experience with scientific codes is almost the opposite -
that they often run like a dog (if at all) in Windows. But I wouldn't
say it had anything to do with floating point in particular. Poor memory
management and process priority management has more to do with it. Those
things are strongly operating system related. But this veers to far from
Fortran and too near to flame-bait, so I'll not argue the point.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Charles Russell wrote:
> Brooks Moses wrote:
>> Why switch?  I'm currently running GFortran on Linux in a VMWare virtual 
>> machine on my Windows box.  Best of both worlds.
>>
> Sounds interesting, but the VMWare web site tells nothing about costs or 
> capabilities unless you first register.  Wikipedia was more informative 
> but still gave no idea what it costs to get into that game. Some of the 
> VMware software seems to be free, but are the free tools sufficient to 
> compile and run gfortran or g95?

The free tools are indeed sufficient, and are what I use.

The brief overview is this: A "virtual machine" consists of a 
(plaintext) specification file that describes some aspects of the 
machine environment, and then some "virtual disk" files that consist of 
another (plaintext) specification file for each disk and some binary 
files containing the disks' data.  Aside from the data on the "disks", 
this is entirely a specification of the virtual hardware.

To run an already-existing virtual machine, all you need is the VMWare 
Player program, which is a free download.

To create a new virtual machine or new virtual disks from scratch, you 
need the VMWare Workstation product which is not free.

However, from VMWare's website, you can download virtual machines that 
other people have created and preloaded software on.  There are quite a 
few of them with various different free operating systems already 
installed; I used one of the Debian ones.

Also, since the configuration files are plaintext, so there's some 
modifying that you can do to existing virtual machines with just a text 
editor.  Adjusting the memory in a virtual machine just requires 
changing the "memsize =" line in the config file.  And it's relatively 
straightforward to copy and rename the disk files, edit the copied disk 
configuration file to point at the copied disk data files, and add a 
couple of lines to the machine configuration file to access the new disk.

I ended up cloning the 4gb "disk" that came with the Debian machine a 
couple of times to add space, but I believe the initial 4gb disk is 
sufficient to get started with compiling gfortran.  It's also helpful to 
bump up the system memory a bit from 128MB, if you've got enough real 
memory on your physical machine, but again that's not really necessary.

- Brooks


-- 
The "bmoses-nospam" address is valid; no unmunging needed.

In article <45AD7B7D.3060904@cits1.stanford.edu>, Brooks Moses wrote:
>> Sounds interesting, but the VMWare web site tells nothing about costs or 
>> capabilities unless you first register.  Wikipedia was more informative 
>> but still gave no idea what it costs to get into that game. Some of the 
>> VMware software seems to be free, but are the free tools sufficient to 
>> compile and run gfortran or g95?
> 
> The free tools are indeed sufficient, and are what I use.
> 
> The brief overview is this: A "virtual machine" consists of a 
> (plaintext) specification file that describes some aspects of the 
> machine environment, and then some "virtual disk" files that consist of 
> another (plaintext) specification file for each disk and some binary 
> files containing the disks' data.  Aside from the data on the "disks", 
> this is entirely a specification of the virtual hardware.
> 
> To run an already-existing virtual machine, all you need is the VMWare 
> Player program, which is a free download.
> 
> To create a new virtual machine or new virtual disks from scratch, you 
> need the VMWare Workstation product which is not free.

Actually, "VMWare Server" is free and does most of the things the
workstation edition does. Including pointy-clicky GUI to edit VM
settings so you don't need to mess around with config files, as well
as creating new VM:s.


-- 
Janne Blomqvist

> It also makes me nervous the as an Intel product, it will work fine for 
> applications on Intel CPUs but what about AMD CPUs. Does anyone have 
> experience with AMD processors using an Intel compiler?

That group is selling a compiler, not processors. IIRC, they explicitly 
support optimization switches for the AMD processors now. In any case, any
code that tags off Intel's CPUIDs (e.g, as is/was in Intel's MKL) are easily
worked around.

	Jan

Hi Richard,

You may well be right, I am by no means an expert on OS behaviors or 
computational details within an OS. My intention was not to start any 
controversial threads but looking for a solution for a problem.

Thanks,
Rod

"Richard Maine" <nospam@see.signature> wrote in message 
news:1hs1lvd.2l4kzjqbgyg3N%nospam@see.signature...
> Grogley <grogley@!nospam!yahoo.com> wrote:
>
>> I guess it has always been my
>> impression that Unix/Linux systems were not particularly efficient at
>> floating point calculations.
>
> That makes very little sense, insomuch as floating point calculation
> generally has very little to do with the operating system.
>
> My general experience with scientific codes is almost the opposite -
> that they often run like a dog (if at all) in Windows. But I wouldn't
> say it had anything to do with floating point in particular. Poor memory
> management and process priority management has more to do with it. Those
> things are strongly operating system related. But this veers to far from
> Fortran and too near to flame-bait, so I'll not argue the point.
>
> -- 
> Richard Maine                    | Good judgement comes from experience;
> email: last name at domain . net | experience comes from bad judgement.
> domain: summertriangle           |  -- Mark Twain 

Jan,

That is what I had hoped to be the case but you never know in what will 
happen in business these days. AMD and Intel are at each other tooth and 
nail and in business, any advantage that can be had will generally be used.

Thanks.
Rod

"Jan Vorbr�ggen" <jvorbrueggen@not-mediasec.de> wrote in message 
news:516a6iF1iivihU1@mid.individual.net...
>> It also makes me nervous the as an Intel product, it will work fine for 
>> applications on Intel CPUs but what about AMD CPUs. Does anyone have 
>> experience with AMD processors using an Intel compiler?
>
> That group is selling a compiler, not processors. IIRC, they explicitly 
> support optimization switches for the AMD processors now. In any case, any
> code that tags off Intel's CPUIDs (e.g, as is/was in Intel's MKL) are 
> easily
> worked around.
>
> Jan 

Hi Rod

Well, I Googled for you (duhh) and didn't find a link to VS 2003 on the
first page of results so concluded that it was no longer available.
Then I checked the Intel site and they now proclaim that the latest
version of their compiler will integrate with VS 2005 and I sort of
trust them on that, they're pretty good guys.

So your homework is to find and download yourself a free edition of MS
VS 2005 C++.

Cheers
Mark


Grogley wrote:

> Hi Mark,
>
> Thanks. Where did you get your free download? From Microsoft directly? I do
> have a copy of the developers studio with my current package. It is labeled
> Developers Studio '97. Wow, ten years old already, so you can tell how much
> I have used this package in the last few years. I guess this package is too
> old to use with the current Intel compiler.
>
> It also makes me nervous the as an Intel product, it will work fine for
> applications on Intel CPUs but what about AMD CPUs. Does anyone have
> experience with AMD processors using an Intel compiler?
>
> Thanks again.
>
> Rod
>
> "Mark Westwood" <markc.westwood@gmail.com> wrote in message
> news:1168966776.154854.34750@s34g2000cwa.googlegroups.com...
> > Hi
> >
> > I have an installation of Intel Fortran v9.something on my Windows XP
> > PC.  I also have the free download (at least, I believe it was free to
> > download) of MS Visual Studio .NET 2003 which I use as the front-end to
> > the compiler, linker etc.  The integration is fine.  When I set up my
> > DE Intel Fortran did not play nicely with VS 2005 and I've had no
> > reason to change the GUI in the last year or so.
> >
> > As to C++'s relationship to Fortran -- well, I get involved in a fair
> > bit of multi-language system building for my sins.  But then I'm paid
> > to endure that sort of pain.
> >
> > Regards
> > Mark Westwood
> >
> > On 15 Jan, 22:21, "Nobody" <nob...@nowhere.net> wrote:
> >> Thanks for your input Tim. Linux/Unix is not really a viable option for
> >> me
> >> for a couple of reasons. Linux seems to be too platform dependent, is way
> >> too arcane to administer and is (arguably) computationally slow compared
> >> to
> >> Windows. While the lure of cheap/free OS and tools is compelling, I have
> >> drunk way too much Microsoft Kool-Aid to switch systems.
> >>
> >> I was hoping some of the gurus on this forum would be familiar with my
> >> current compiler and have a compiler option which would magically solve
> >> my
> >> problem. I did do some checking and the Intel Fortran can be purchased
> >> relatively inexpensively but I need the MS developers package with C++ to
> >> install this which equates to more expense. (I am not sure what C++ has
> >> to
> >> do with anything related to Fortran though.) I have to decide if my
> >> little
> >> hobby is worth the cost and effort.
> >>
> >> Thanks again!
> >> Rod"Tim Prince" <tpri...@nospamcomputer.org> wrote in
> >> messagenews:QK5qh.34044$Gr2.1427@newssvr21.news.prodigy.net...
> >>
> >>
> >>
> >> >> I recompile this same multithreaded application and run it on my
> >> >> current
> >> >> machine. I load it up with about 50 threads but my twin cores run only
> >> >> 50% busy. This indicates to me that while the OS sees these threads as
> >> >> unique, they are not being utilized (not sure what the right term is)
> >> >> the
> >> >> same way as on the older SMP WIN NT systems. I did try this
> >> >> application
> >> >> on an older dual processor system running Win 2K and the result was
> >> >> the
> >> >> same on the new dual core system.
> >>
> >> >> So my long winded question: Is there something fundamentally different
> >> >> in
> >> >> the way threads are treated now and is there a easy way, like a
> >> >> compile
> >> >> or link option (not bloody likely I suspect) open to me so that I can
> >> >> utilize both processing cores efficiently?
> >>
> >> > If your implicit ground rule is Windows only, free compilers only, your
> >> > options
> >> > are few.  The easy way to meet your goals is with OpenMP.  gfortran 4.2
> >> > and 4.3 incorporate OpenMP, but not on Windows, so you
> >> > would need linux, if you want free OpenMP, as gnu OpenMP is not
> >> > implemented on Windows.
> >> > OpenMP is built on the usual threading capabilities of the OS (Windows
> >> > threads, or pthreads for linux), so the basic capability is there even
> >> > without an OpenMP compiler.  Threads generally have to be managed in C.
> >> > Current commercial Fortran compilers incorporate OpenMP and (for the
> >> > right
> >> > combinations of compiler and CPU brands) built-in methods for pinning
> >> > threads to processors.
> >

Hi Rod

Well, I Googled for you (duhh) and didn't find a link to VS 2003 on the
first page of results so concluded that it was no longer available.
Then I checked the Intel site and they now proclaim that the latest
version of their compiler will integrate with VS 2005 and I sort of
trust them on that, they're pretty good guys.

So your homework is to find and download yourself a free edition of MS
VS 2005 C++.

Cheers
Mark


Grogley wrote:

> Hi Mark,
>
> Thanks. Where did you get your free download? From Microsoft directly? I do
> have a copy of the developers studio with my current package. It is labeled
> Developers Studio '97. Wow, ten years old already, so you can tell how much
> I have used this package in the last few years. I guess this package is too
> old to use with the current Intel compiler.
>
> It also makes me nervous the as an Intel product, it will work fine for
> applications on Intel CPUs but what about AMD CPUs. Does anyone have
> experience with AMD processors using an Intel compiler?
>
> Thanks again.
>
> Rod
>
> "Mark Westwood" <markc.westwood@gmail.com> wrote in message
> news:1168966776.154854.34750@s34g2000cwa.googlegroups.com...
> > Hi
> >
> > I have an installation of Intel Fortran v9.something on my Windows XP
> > PC.  I also have the free download (at least, I believe it was free to
> > download) of MS Visual Studio .NET 2003 which I use as the front-end to
> > the compiler, linker etc.  The integration is fine.  When I set up my
> > DE Intel Fortran did not play nicely with VS 2005 and I've had no
> > reason to change the GUI in the last year or so.
> >
> > As to C++'s relationship to Fortran -- well, I get involved in a fair
> > bit of multi-language system building for my sins.  But then I'm paid
> > to endure that sort of pain.
> >
> > Regards
> > Mark Westwood
> >
> > On 15 Jan, 22:21, "Nobody" <nob...@nowhere.net> wrote:
> >> Thanks for your input Tim. Linux/Unix is not really a viable option for
> >> me
> >> for a couple of reasons. Linux seems to be too platform dependent, is way
> >> too arcane to administer and is (arguably) computationally slow compared
> >> to
> >> Windows. While the lure of cheap/free OS and tools is compelling, I have
> >> drunk way too much Microsoft Kool-Aid to switch systems.
> >>
> >> I was hoping some of the gurus on this forum would be familiar with my
> >> current compiler and have a compiler option which would magically solve
> >> my
> >> problem. I did do some checking and the Intel Fortran can be purchased
> >> relatively inexpensively but I need the MS developers package with C++ to
> >> install this which equates to more expense. (I am not sure what C++ has
> >> to
> >> do with anything related to Fortran though.) I have to decide if my
> >> little
> >> hobby is worth the cost and effort.
> >>
> >> Thanks again!
> >> Rod"Tim Prince" <tpri...@nospamcomputer.org> wrote in
> >> messagenews:QK5qh.34044$Gr2.1427@newssvr21.news.prodigy.net...
> >>
> >>
> >>
> >> >> I recompile this same multithreaded application and run it on my
> >> >> current
> >> >> machine. I load it up with about 50 threads but my twin cores run only
> >> >> 50% busy. This indicates to me that while the OS sees these threads as
> >> >> unique, they are not being utilized (not sure what the right term is)
> >> >> the
> >> >> same way as on the older SMP WIN NT systems. I did try this
> >> >> application
> >> >> on an older dual processor system running Win 2K and the result was
> >> >> the
> >> >> same on the new dual core system.
> >>
> >> >> So my long winded question: Is there something fundamentally different
> >> >> in
> >> >> the way threads are treated now and is there a easy way, like a
> >> >> compile
> >> >> or link option (not bloody likely I suspect) open to me so that I can
> >> >> utilize both processing cores efficiently?
> >>
> >> > If your implicit ground rule is Windows only, free compilers only, your
> >> > options
> >> > are few.  The easy way to meet your goals is with OpenMP.  gfortran 4.2
> >> > and 4.3 incorporate OpenMP, but not on Windows, so you
> >> > would need linux, if you want free OpenMP, as gnu OpenMP is not
> >> > implemented on Windows.
> >> > OpenMP is built on the usual threading capabilities of the OS (Windows
> >> > threads, or pthreads for linux), so the basic capability is there even
> >> > without an OpenMP compiler.  Threads generally have to be managed in C.
> >> > Current commercial Fortran compilers incorporate OpenMP and (for the
> >> > right
> >> > combinations of compiler and CPU brands) built-in methods for pinning
> >> > threads to processors.
> >

Hi Rod

Well, I Googled for you (duhh) and didn't find a link to VS 2003 on the
first page of results so concluded that it was no longer available.
Then I checked the Intel site and they now proclaim that the latest
version of their compiler will integrate with VS 2005 and I sort of
trust them on that, they're pretty good guys.

So your homework is to find and download yourself a free edition of MS
VS 2005 C++.

Cheers
Mark


Grogley wrote:

> Hi Mark,
>
> Thanks. Where did you get your free download? From Microsoft directly? I do
> have a copy of the developers studio with my current package. It is labeled
> Developers Studio '97. Wow, ten years old already, so you can tell how much
> I have used this package in the last few years. I guess this package is too
> old to use with the current Intel compiler.
>
> It also makes me nervous the as an Intel product, it will work fine for
> applications on Intel CPUs but what about AMD CPUs. Does anyone have
> experience with AMD processors using an Intel compiler?
>
> Thanks again.
>
> Rod
>
> "Mark Westwood" <markc.westwood@gmail.com> wrote in message
> news:1168966776.154854.34750@s34g2000cwa.googlegroups.com...
> > Hi
> >
> > I have an installation of Intel Fortran v9.something on my Windows XP
> > PC.  I also have the free download (at least, I believe it was free to
> > download) of MS Visual Studio .NET 2003 which I use as the front-end to
> > the compiler, linker etc.  The integration is fine.  When I set up my
> > DE Intel Fortran did not play nicely with VS 2005 and I've had no
> > reason to change the GUI in the last year or so.
> >
> > As to C++'s relationship to Fortran -- well, I get involved in a fair
> > bit of multi-language system building for my sins.  But then I'm paid
> > to endure that sort of pain.
> >
> > Regards
> > Mark Westwood
> >
> > On 15 Jan, 22:21, "Nobody" <nob...@nowhere.net> wrote:
> >> Thanks for your input Tim. Linux/Unix is not really a viable option for
> >> me
> >> for a couple of reasons. Linux seems to be too platform dependent, is way
> >> too arcane to administer and is (arguably) computationally slow compared
> >> to
> >> Windows. While the lure of cheap/free OS and tools is compelling, I have
> >> drunk way too much Microsoft Kool-Aid to switch systems.
> >>
> >> I was hoping some of the gurus on this forum would be familiar with my
> >> current compiler and have a compiler option which would magically solve
> >> my
> >> problem. I did do some checking and the Intel Fortran can be purchased
> >> relatively inexpensively but I need the MS developers package with C++ to
> >> install this which equates to more expense. (I am not sure what C++ has
> >> to
> >> do with anything related to Fortran though.) I have to decide if my
> >> little
> >> hobby is worth the cost and effort.
> >>
> >> Thanks again!
> >> Rod"Tim Prince" <tpri...@nospamcomputer.org> wrote in
> >> messagenews:QK5qh.34044$Gr2.1427@newssvr21.news.prodigy.net...
> >>
> >>
> >>
> >> >> I recompile this same multithreaded application and run it on my
> >> >> current
> >> >> machine. I load it up with about 50 threads but my twin cores run only
> >> >> 50% busy. This indicates to me that while the OS sees these threads as
> >> >> unique, they are not being utilized (not sure what the right term is)
> >> >> the
> >> >> same way as on the older SMP WIN NT systems. I did try this
> >> >> application
> >> >> on an older dual processor system running Win 2K and the result was
> >> >> the
> >> >> same on the new dual core system.
> >>
> >> >> So my long winded question: Is there something fundamentally different
> >> >> in
> >> >> the way threads are treated now and is there a easy way, like a
> >> >> compile
> >> >> or link option (not bloody likely I suspect) open to me so that I can
> >> >> utilize both processing cores efficiently?
> >>
> >> > If your implicit ground rule is Windows only, free compilers only, your
> >> > options
> >> > are few.  The easy way to meet your goals is with OpenMP.  gfortran 4.2
> >> > and 4.3 incorporate OpenMP, but not on Windows, so you
> >> > would need linux, if you want free OpenMP, as gnu OpenMP is not
> >> > implemented on Windows.
> >> > OpenMP is built on the usual threading capabilities of the OS (Windows
> >> > threads, or pthreads for linux), so the basic capability is there even
> >> > without an OpenMP compiler.  Threads generally have to be managed in C.
> >> > Current commercial Fortran compilers incorporate OpenMP and (for the
> >> > right
> >> > combinations of compiler and CPU brands) built-in methods for pinning
> >> > threads to processors.
> >

Mark Westwood wrote:

> Well, I Googled for you (duhh) and didn't find a link to VS 2003 on the
> first page of results so concluded that it was no longer available.
> Then I checked the Intel site and they now proclaim that the latest
> version of their compiler will integrate with VS 2005 and I sort of
> trust them on that, they're pretty good guys.
>
> So your homework is to find and download yourself a free edition of MS
> VS 2005 C++.

There is a free Microsoft Visual C++ 2005 Express Edition, and this
works fine with Intel Fortran 9.1 from the command line.  However,
Microsoft has structured the "Express Edition" so that it does not
permit IDE integration of any third-party compiler so it does not work
as a complete solution.

I'm not aware that MS ever made VC++ 2003 (the full version with the
IDE) available as a free download.  There was a "Visual C++ 2003
Toolkit" which was command-line tools only and that was free.

The least expensive MS prerequisite product for Intel Fortran 9.1 is
Visual Studio 2005 Standard Edition, which can be had for less than
$250.  If you are entitled to academic pricing, it is much less (as is
Intel Fortran).

Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
  http://softwareforums.intel.com/
Intel Fortran Support
  http://developer.intel.com/software/products/support/
My Fortran blog
  http://www.intel.com/software/drfortran

Janne Blomqvist wrote:
> In article <45AD7B7D.3060904@cits1.stanford.edu>, Brooks Moses wrote:
>> To create a new virtual machine or new virtual disks from scratch, you 
>> need the VMWare Workstation product which is not free.
> 
> Actually, "VMWare Server" is free and does most of the things the
> workstation edition does. Including pointy-clicky GUI to edit VM
> settings so you don't need to mess around with config files, as well
> as creating new VM:s.

Thanks for the correction!  I wonder if that's something new since I was 
looking into this, or if I just missed something.

- Brooks


-- 
The "bmoses-nospam" address is valid; no unmunging needed.

Grogley wrote:

> I guess the Linus being slow to Windows comes from empirical evidence I
> have seen over the years and no real hard testing. The one recent test I
> have done is using DSL (Damn Small Linux) on an older machine. Since I
> also have few systems running Einstein@Home, the DSL system benchmark was
> about 30% slower than the same machine running Win 2K. In the old days, I
> compiled my simulation on a Sun Unix system and it ran significantly
> slower than I was expecting given its benchmarks at the time. I guess it
> has always been my impression that Unix/Linux systems were not
> particularly efficient at floating point calculations.

This is too weird.  What does your simulation simulate?  I'm amazed that
this thread has generated so much traffic while you've avoided describing
the problem you are actually 'simulating' in your spare time.  In my
experience, hobbyists (especially ones wedded to wild, un-demonstrable
statements about speed, OS, compilers etc.) often are tackling the wrong
problem or using poor algorithms.  My background is CFD, and I won't be
able to put my hand on a "large enough", "fast enough" computer till around
2085.  That doesn't keep me from doing real work in the mean time.  And in
general, things concerning OS administration and my 'comfort-level' always
gets relegated to the back seat.

So what are you doing?  There might actually be some people here that could
help you speed up your algorithms or improve your Fortran performance.

Ed
   

In <Wazrh.16970$ZT3.9634@newssvr19.news.prodigy.com> AeroSpace Ed:

[Snip...]

> So what are you doing?

IMO: trolling, and lamely. Personally, I plonk 'em if they're wasting time.

HTH; YMMV...

-- 
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at airmail, dotted with net. DO NOT SPAM IT.
Kids jumping ship? Looking to hire an old-school type? Email me.

Well, I am not a troll and I apologize if I ruffled any feathers, that was 
not my intention. I have been playing with many-body simulations since I was 
a graduate student 80's. My statements concerning speed of calculations are 
based on my observations over the years working with small systems of 
objects, not huge server clusters or what ever the current state of the art 
is.  I also have no doubt that the people here could help me improve my 
algorithms. Had I wanted to do that I would have asked that. Bottom line for 
me is that as I said in my first post, I have programming hack, who doesn't 
really want to invest the time in rewriting my old code. I just enjoy 
playing with these simulations, which may run for a year in the background 
of my computer before I start a new run.

However, that was not the point of my question. My original question was 
concerning my 10 year old compiler and if could support proper 
multithreading on WinXP. Since it is the opinion of those who responded here 
that my current compiler won't do, I have to examine other options.

Thanks to all who responded.
Rod


"AeroSpace Ed" <mimihoohoo@sbcglobal.net> wrote in message 
news:Wazrh.16970$ZT3.9634@newssvr19.news.prodigy.com...
> Grogley wrote:
>
>> I guess the Linus being slow to Windows comes from empirical evidence I
>> have seen over the years and no real hard testing. The one recent test I
>> have done is using DSL (Damn Small Linux) on an older machine. Since I
>> also have few systems running Einstein@Home, the DSL system benchmark was
>> about 30% slower than the same machine running Win 2K. In the old days, I
>> compiled my simulation on a Sun Unix system and it ran significantly
>> slower than I was expecting given its benchmarks at the time. I guess it
>> has always been my impression that Unix/Linux systems were not
>> particularly efficient at floating point calculations.
>
> This is too weird.  What does your simulation simulate?  I'm amazed that
> this thread has generated so much traffic while you've avoided describing
> the problem you are actually 'simulating' in your spare time.  In my
> experience, hobbyists (especially ones wedded to wild, un-demonstrable
> statements about speed, OS, compilers etc.) often are tackling the wrong
> problem or using poor algorithms.  My background is CFD, and I won't be
> able to put my hand on a "large enough", "fast enough" computer till 
> around
> 2085.  That doesn't keep me from doing real work in the mean time.  And in
> general, things concerning OS administration and my 'comfort-level' always
> gets relegated to the back seat.
>
> So what are you doing?  There might actually be some people here that 
> could
> help you speed up your algorithms or improve your Fortran performance.
>
> Ed
> 

AeroSpace Ed  <mimihoohoo@sbcglobal.net> wrote:

>My background is CFD, and I won't be
>able to put my hand on a "large enough", "fast enough" computer till around
>2085. 

You are an optimist :-)

In article <45AE922B.8010404@cits1.stanford.edu>, Brooks Moses wrote:
> Janne Blomqvist wrote:
>> In article <45AD7B7D.3060904@cits1.stanford.edu>, Brooks Moses wrote:
>>> To create a new virtual machine or new virtual disks from scratch, you 
>>> need the VMWare Workstation product which is not free.
>> 
>> Actually, "VMWare Server" is free and does most of the things the
>> workstation edition does. Including pointy-clicky GUI to edit VM
>> settings so you don't need to mess around with config files, as well
>> as creating new VM:s.
> 
> Thanks for the correction!  I wonder if that's something new since I was 
> looking into this, or if I just missed something.

IIRC it was released 6 months ago or something like that, presumably
as an answer against other free virtualization products that are
beginning to appear (Xen, MS virtual PC, KVM, etc.).


-- 
Janne Blomqvist

Richard Maine wrote:
> Grogley <grogley@!nospam!yahoo.com> wrote:
>
> > I guess it has always been my
> > impression that Unix/Linux systems were not particularly efficient at
> > floating point calculations.
>
> That makes very little sense, insomuch as floating point calculation
> generally has very little to do with the operating system.
>
> My general experience with scientific codes is almost the opposite -
> that they often run like a dog (if at all) in Windows.

The 16 codes of the Polyhedron Fortran benchmark run on both Windows
and Linux, and comparing the results at
http://www.polyhedron.com/pb05/win32/f90bench_p4.html and
http://www.polyhedron.com/pb05/linux/f90bench_p4.html , there are some
compilers available for both platforms where the Windows version was
slower -- the geometric means for Lahey on Windows and Linux are 38.0
and
29.0 seconds, but for Intel, generally the fastest compiler
benchmarked, the times were essentially the same, 24.0 and 23.7
seconds.

The Polyhedron results do not confirm the criticisms made of Windows.

> But I wouldn't
> say it had anything to do with floating point in particular. Poor memory
> management and process priority management has more to do with it. Those
> things are strongly operating system related. But this veers to far from
> Fortran and too near to flame-bait, so I'll not argue the point.

Beliavsky <beliavsky@aol.com> wrote:
 
> The 16 codes of the Polyhedron Fortran benchmark run on both Windows
> and Linux, and comparing the results at
> http://www.polyhedron.com/pb05/win32/f90bench_p4.html and
> http://www.polyhedron.com/pb05/linux/f90bench_p4.html , there are some
> compilers available for both platforms where the Windows version was
> slower -- the geometric means for Lahey on Windows and Linux are 38.0
> and
> 29.0 seconds, but for Intel, generally the fastest compiler
> benchmarked, the times were essentially the same, 24.0 and 23.7
> seconds.
 
> The Polyhedron results do not confirm the criticisms made of Windows.

The criticisms I usually make about Windows are mostly I/O related.
For a compute bound problem with limited I/O you shouldn't see much
difference, assuming everything else is constant.
 
>> But I wouldn't
>> say it had anything to do with floating point in particular. Poor memory
>> management and process priority management has more to do with it. Those
>> things are strongly operating system related. But this veers to far from
>> Fortran and too near to flame-bait, so I'll not argue the point.

If the tests are done on an unloaded system there shouldn't be much
process priority management.  Assuming enough real memory, there 
shouldn't be much memory management.  

-- glen