# Speed up calculations



## kandombe (Mar 23, 2006)

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,


----------



## barhar (Mar 23, 2006)

'... 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/').


----------



## lurk (Mar 23, 2006)

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!


----------



## kandombe (Mar 23, 2006)

barhar said:
			
		

> yet, the processor speed of the Pentium IV is not listed.


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.


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.


----------



## kandombe (Mar 23, 2006)

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.


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.


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.


----------



## lurk (Mar 23, 2006)

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.


----------



## kandombe (Mar 24, 2006)

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.


----------



## lurk (Mar 24, 2006)

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.


----------



## davebz (Mar 30, 2006)

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.


----------



## kandombe (Apr 3, 2006)

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


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.


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


----------



## lurk (Apr 3, 2006)

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?


----------



## ElDiabloConCaca (Apr 3, 2006)

...I think I'm with lurk on this one... the PowerMac G5s also had a processor setting, and if it were set to anything other than "Highest," the processor may not be utilized to its fullest.

In single-user mode, the processor isn't controlled by software (I believe), causing it to run at full-speed as default.

http://docs.info.apple.com/article.html?artnum=86527


----------



## kandombe (Apr 12, 2006)

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?



Yeah, it's a laptop. Do you think this is relevant?


----------



## davebz (Apr 12, 2006)

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/


----------



## ElDiabloConCaca (Apr 12, 2006)

kandombe said:
			
		

> Sorry for not saying anything before, but I haven't got too much time to enter the forum during these days.
> 
> Yeah, it's a laptop. Do you think this is relevant?


Could it be that your processor setting is not at "Highest"?

http://docs.info.apple.com/article.html?artnum=86527


----------



## lurk (Apr 12, 2006)

ElD,

That was my suspicion.  We will see...


----------



## ElDiabloConCaca (Apr 12, 2006)

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.


----------



## kandombe (Apr 26, 2006)

Sorry, I've been out for some time.



			
				ElDiabloConCaca said:
			
		

> Could it be that your processor setting is not at "Highest"?



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.


----------

