[OS X TeX] multi cores

Peter Dyballa Peter_Dyballa at Web.DE
Wed Dec 16 12:54:36 CET 2009


Am 16.12.2009 um 02:50 schrieb George Gratzer:

>> You are using the shell's built-in timer, which cannot be very  
>> exact. In bash and GNU's date command, i.e., the command gdate,  
>> which has a resolution of nsec, you could run
>>
>> 	START=$(gdate +%s.%N) ; latex -interaction=batchmode GLT3 ; END=$ 
>> (gdate +%s.%N) ; DIFF=$(echo "$END - $START" | bc) ; echo $DIFF
>
>
> This gives:
>
>
> (standard_in) 2: parse error

I presume the "parse error" happens in your gdate, which is not the  
real GNU date. To check this invoke on the command line:

	gdate "+%A, der %x %X.%N %Z %z"

It'll output something like: "Mittwoch, der 16.12.2009  
12:24:48.900835000 CET +0100" – and you can see here that my G4 clock  
is only exact to the µsec! (At least in gdate.)

>
>
>> This one-liner will measure from start to end of the execution. The  
>> DIFF value times four (you mentioned once that not all the cores  
>> are used) might give the "real" time. Another approach is to use  
>> Sun's built-in DTraceToolkit:
>>
>> 	sudo procsystime -eoT latex -interaction=batchmode GLT3
>
> I tried this. I got
>
>         SYSCALL          TIME (ns)
>   thread_selfid               1387
>         geteuid               1441
> ...
>           ioctl            6244794
>  write_nocancel            7047911
>   read_nocancel           11918684
>          access           26760916
>          TOTAL:           60578713
>
> CPU Times for command latex -interaction=batchmode GLT3,
>
>         SYSCALL          TIME (ns)
>   thread_selfid                259
>         geteuid                340
> ...
>           ioctl            6241617
>  write_nocancel            6316663
>   read_nocancel            7924768
>          access           15639946
>          TOTAL:           42422149
>
> What does it mean?


The first table lists the total elapsed time of all system or library  
calls latex performed while converting the TEX file to PDF, the second  
table shows how long one call lasted on *any* one, a real or a virtual  
one, of the CPUs used. (By using -ceoT you could get a table with the  
number of function calls happened.) The list of functions called is  
not exact, many more were used, but these were internal functions.  
DTrace can only see what is directed to the system.

What one can see from the two tables is that some calls a very  
expensive, for example the four I cited from your message.


After all I have to start believing that Snow Leopard, the i7 CPU, and  
TeX are extremely fast and efficient: 60 msec of actual CPU (or CPUs?)  
use time for external system ressources. Incredible... (and I'm  
starting to feel the need for an i7/i5 MacBook! What I see on my G4 is  
a factor of 50-100 for the actual process time in relation to the use  
time of "external" ressources.)

--
Greetings

   Pete

The best way to accelerate a PC is 9.8 m/s² – not that much!




More information about the macostex-archives mailing list