Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29238 Discussions

OS for dedicated console app simulations

aqmconsultant
Beginner
733 Views

Newbie to this forum, with a seriously old-school question --

I have a large number of CPU-intensive simulations to run, using a 32-bit console (DOS) app. Simulation times are on the order of dozens of hours each on one core of an AMD x2 4800+ (virtually all CPU cycles, v. little IO).I plan to build several very basic boxes to run these (1/2 Gb RAM, fast CPU, small HDD). To minimize costs of OS's I'm considering using Win98 (I have several licenses not currently in use) or FreeDOS. Need to have FAT32 and basic networking at least. So the question:

Does anyone have any experience with relative throughput for moderately optimized Visual Fortran console apps for different DOS versions? Recommendations? The model code is 90's vintage F77 and F95.

TIA

0 Kudos
5 Replies
Steven_L_Intel1
Employee
733 Views
Stay away from Windows 95/98. You want NT4 or Windows 2000, at least. Windows Server 2003 would be ok too. XP would work but there's additional stuff there that probably would get in your way. FreeDOS would not work - at least if you want to use Intel Fortran.

Let me suggest that you consider the upcoming (real soon now) Conroe processor instead of the AMD. You'll get better performance with lower power consumption. Would this application benefit from use of two cores? Try autoparallel to see what you get.

0 Kudos
dbruceg
Beginner
733 Views

I'm interested in doing precisely the same thing. If one gets an Intel Fortrancode up and running on Windows, and one uses the Intel language extensions rather than calls into theWindows API (observing OS dependencies), will the code immediately port to UNIX or LINUX? At least theoretically? If so, wouldn't a stripped-down UNIX OS be an option?

Bruce

0 Kudos
Steven_L_Intel1
Employee
733 Views
Yes, assuming that you recompiled with the Linux compiler. I agree that's a good choice for such a thing.
0 Kudos
dbruceg
Beginner
733 Views

Thanks. And incidentally, with regard to the Intel FORTRAN extensions, I think you guys have done a great job. I'm upgrading a pretty old code, and with your extensions, isolated in a relatively small set of wrapper routines, I have completely eliminated the plethora ofMASM and C routines from the original code.

Bruce

0 Kudos
jimdempseyatthecove
Honored Contributor III
733 Views

I assume you have Windows XP Pro (or Windows 2000, or 2003 server). And I assume you have or can put together one Win98 test platform. And I assume you have Intel Visual Fortran (your on the IVF forum). Therefor, I suggest you go through the exercise of writing a test Win32 Console Application that:

a) Opens a test input data file
b) Reads the data
c) Opens (creates) a test output data file
d) Writes the data
e) closes files
f) exits with completion status

Create the application on the development platform using static libraries.

Also pick systems that have SSE3 instructions (3DNow) such that any compiler optimizations selected (except set auto parallel off and OpenMP off) work on both processors (development system and target test system).

Then copy the executable over to the Win98 system and try to run it.

If the test app does not run on Win98 then copy it to any available WinXP system. If it will not run there either then perhaps you may require a Intel Fortran runtime component (error messages hopefully will tell what is required).

If this runs then try compiling your simulation application. Get it to run on your development platform first. Then see if it will run on the target platform.

If your are unable to get the test app to run on Win98 then assume you will require a 32-bit O/S. Some versions of Linux have a Win32 interface filter which can be used to run most Win32 applications. Since your applicationhas limited O/S requirements you should be able to find a combination that works. But this adds to the "screwing around" time.

You stated that you intend to use several very basic boxes to run your application. I assume your simulation program is floating point intensive. The processors to choose should have SSE3 (AMD 3DNow) instructions as it may have more performance impact on your simulation than using more processors.

A system box w/ hd, RAM, NIC - without KB, Mouse, VideoMonitor and without O/S is almost the same cost as the same system with OEM version of WinXP. True, their is a difference in cost in equipment. But this has to be traded off against the aggravation cost (time spent) in trying to get you application to run on "free" operating systems. If you intend to purchase 10's of boxes the purchase price of the O/S may not be of much concern. If you intend to purchase 100's of boxes then the O/S price will be of concern.

Win98 cannot use Dual Core processors - WinXP can (so can someLinux distros). Therefore, a system box w/ Dual Core Processor, hd, RAM, NIC - without KB, Mouse, VideoMonitor + Windows XP (OEM) will likely cost less than two of the previoudly mentioned single core system boxes running the "free" Win98's in your possesion.

I went through a similar situation where I acquired a simulation package written in F77 which had a ~25 year development history. Due to memory restrictions on systems that long ago and due to feature enhancements throughout those years this simulator worked - but not optimally. Estimations of my computation requirements were (if everything worked as planned (never does)) was that I was looking at over 3 years of computation time.

Spending time with a profiler initially produced a 4x faster application then eventually with more work up to 10x faster for the single threaded application. This particular simulation could take advantage of parallelizat ion. Using OpenMP, and a little time on the learning curve,I was able to parallel-ize the simulator. To take advantage of this I acquired a 2 processor 4 core server box on eBay and installed WinXP Pro. The simulation utilizes 75% of the processing resources and the wall clock times are now 30x times faster. I am quite pleased with the results of the efforts to "tune" the simulation code. Maybe you will have a similar experience.

Jim Dempsey

0 Kudos
Reply