Speed up calculations

K

kandombe

Registered
Hi,

I have compiled a Fortran program that does some calculations and I'm not very happy with its speed. I'm running it from the Terminal in a G4 at 550 MHz and the time it takes to run it is more or less the double than what it takes in a Pentium IV.

The point is that if I start the computer in the console mode (Apple-S at startup) it runs in the same time as the Pentium. I've been trying to speed up the execution by changing the priority of the process using 'nice', but with no success.

Does somebody know if there is a way to get in the Terminal the same execution speed as when started in console mode?

Thanks,
 
'... G4 at 550 MHz and the time it takes to run it is more or less the double than what it takes in a Pentium IV' - yet, the processor speed of the Pentium IV is not listed.

'Command S' places the Mac in 'Single User' mode, with very little resources (daemons, etc.) executed; thus, the reason for the speedy Mac.

Once MacOS X is loaded, the Mac approaches the speed of a snail.
'Terminal' is just another application executed within MacOS X; thus, there is no way to have 'Terminal' execute any process(es) faster.

To see the differnece in processes running between 'Single User' mode and MacOS X - in 'Single User' mode enter 'top'. In MacOS X via 'Terminal' enter 'top' or view the processes via 'Activity Monitor' ('/Applications/Utilities/').
 
The thing is that you should not see that much of a difference if you are running in single user mode or with all the bells and whistles running with two big exceptions.

1. Memory - Do you have enough? You can figure this out from the activity monitor app, check how much you are swapping. If this is the problem your only real recourse is to add more memory.

2. Lots of output. If your program generates lots of output to the terminal that can be a real source of slowdown, you will basically be limited by the speed that Terminal.app can refresh. In this case piping your output to a file can be a real winner.

Good Luck!
 
barhar said:
yet, the processor speed of the Pentium IV is not listed.
Click to expand...
It's 2GHz

barhar said:
Once MacOS X is loaded, the Mac approaches the speed of a snail.
'Terminal' is just another application executed within MacOS X; thus, there is no way to have 'Terminal' execute any process(es) faster.
Click to expand...
But even if I agree that you are never going to get the same speed of the 'Single User' mode, there should be a way to set up the priority of the process so that its speed would approach it.
 
lurk said:
1. Memory - Do you have enough? You can figure this out from the activity monitor app, check how much you are swapping. If this is the problem your only real recourse is to add more memory.
Click to expand...
I'm only handling several arrays of 10000 real numbers each one, so the memory shouldn't be a problem. In fact, the memory involved is only 2MB of real memory and 30MB of virtual one.

lurk said:
2. Lots of output. If your program generates lots of output to the terminal that can be a real source of slowdown, you will basically be limited by the speed that Terminal.app can refresh. In this case piping your output to a file can be a real winner.
Click to expand...
I already do my output to a file.
Then, I think the only way is to pause somehow other processes in order to get the maximum of CPU for my program, but the problem is that I don't know how to do it.

Thanks for wishing me good luck.
 
So fire up Activity Monitor.app and see if you are getting enough processor time for your program. You might see that there is another runaway process you are competing with or the like.

Let us know what you see there.
 
I keep on being confused. From the 'Activity Monitor' what I see is that the launched process gets (in average during its execution and without too much dispersion, only 2% of deviation) around 90%CPU. Then, I would expect that the execution time would approach much more that of the 'Single User' mode.
Perhaps there's no solution for this problem.
 
Well it does make it more interesting. If you are getting 90% of the cpu and we assume that you get 99% in single user mode then there should not be that much of a difference. Here is an experiment use the time command to measure your results and post them here. Something like

time myproggy input_file.dat

Which will print out a summary of the time the process took for instance I tested 'ls' in my user directory and got the following three results

#1
real 0m0.176s
user 0m0.001s
sys 0m0.010s

#2
real 0m0.031s
user 0m0.001s
sys 0m0.006s

#3
real 0m0.020s
user 0m0.001s
sys 0m0.006s

Now it is important to run it more than once since as you noticed the first execution is much slower then the later one because the needed files are already in memory (in the built in disk cache). Let us know how those numbers fair.

Also notice that real time does not equal sys + user. Because process might be blocking on the disk or just cpu starved, in which case only the CPU time advances.

Let us know how it works out since you should not be seeing the slowdown you describe without something else going on.
 
I'm no programmer, but is there any way Kandobe could write instructions to call up ALTIVEC for crunching those calculations? If that were the case, then it would certainly speed things up.
 
Sorry for not saying anything before, but I've been too busy for more than one week. With regard to lurk's comment

lurk said:
Here is an experiment use the time command to measure your results and post them here. Something like

time myproggy input_file.dat
Click to expand...
I have compared the results (for a certain input file) and I get from the Terminal

real 0m21.478s
user 0m21.010s
sys 0m0.090s

and using the 'Single User' mode

real 0m13.176s
user 0m13.060s
sys 0m0.060s

Don't ask me where the difference comes from, because I don't understand it.

davebz said:
I'm no programmer, but is there any way Kandobe could write instructions to call up ALTIVEC for crunching those calculations? If that were the case, then it would certainly speed things up.
Click to expand...
I'm also no programmer, but from what I've seen from ALTIVEC, it's mainly oriented to C, and my program is already written in Fortran. Even in the case that I would change my code to optimize the speed in my machine, I would loose the portability of the program.

In any case, thanks to all for your suggestions but I'm afraid that there's not an easy way out
 
Wow, I was expecting a large sys component in there or a big gap with the real time. Neither is a bit troubling as we are getting into the realms of things harder to measure. But there is one little thing that it could still be is this a laptop by chance?
 
Sorry for not saying anything before, but I haven't got too much time to enter the forum during these days.

lurk said:
But there is one little thing that it could still be is this a laptop by chance?
Click to expand...

Yeah, it's a laptop. Do you think this is relevant?
 
Have you checked out Absoft's website? I think they might have what you are looking for. Just discovered they have software that will handle your calculations and route them through Altivec for you. The program compiles fortran to C so it can take advantage of VecLib procedures.

Check it out: http://www.absoft.com/
 
Yeah -- but he seems to have overlooked that post since he didn't mention trying it, and it seems highly likely that that's the culprit... just reminding him to try that before looking at potentially more complicated solutions.
 
Sorry, I've been out for some time.

ElDiabloConCaca said:
Could it be that your processor setting is not at "Highest"?
Click to expand...

No, it was certainly one of the first things I looked at when I saw the difference in performance. The System Preferences are really well selected. I even turned off any periodic proccess running in the background (such as Entourage or Little Snitch) by taking a look with 'ps -x' and killing them, but the CPU time keeps on being the same.
 
You must log in or register to reply here.
Back
Top