Thread View: comp.sys.transputer
2 messages
2 total messages
Started by Mauricio Gomez Calderon
Thu, 07 Jan 1993 20:02
On-chip Ram: Helios, D7205
Author: Mauricio Gomez Calderon
Date: Thu, 07 Jan 1993 20:02
Date: Thu, 07 Jan 1993 20:02
49 lines
1766 bytes
1766 bytes
Hi Again...
I was testing the on-chip RAM for a single Transputer:
In Helios, i tried to accelerate a small test routine, using the
fast on-chip Ram memory. The code is as follows:
void cycle(int iterations) {
int i;
for(i=0; i<iterations; i++) {
/* nothing! */
}
}
In a normal situation, this takes 14 sec for 10,000,000 iterations.
Using on-chip Ram, this takes 6 sec for 10,000,000 iterations.
But in D7205 Occam 2 Toolset, if i try to do the same...
VAL INT iterations IS 10000000:
SEQ
clock ? time1
i := 0
WHILE ( i < iterations )
SEQ
-- nothing!
i := i + 1
clock ? time2
In a normal situation, this takes 10 sec for 10,000,000 iterations.
Using order.code := -1 in the .pgm this takes 14 sec for the same iterations.
I suppose that this occurs because the occonf try to optimize by default
the use of the on-chip RAM for small routines...
But what about the best times? 6 sec in Helios and 10 sec in D7205 for the
almost 'same' application... Furthermore, the occam process is the only
process in the transputer...
Why this difference? Thanks in Advance...
Maurro
Re: On-chip Ram: Helios, D7205
Author: Conor O'Neill
Date: Fri, 08 Jan 1993 17:57
Date: Fri, 08 Jan 1993 17:57
89 lines
3383 bytes
3383 bytes
In article <1993Jan07.200247.37029@dcc.uchile.cl> maurro@inf.utfsm.cl (Mauricio Gomez Calderon) writes:
> But what about the best times? 6 sec in Helios and 10 sec in D7205 for the
> almost 'same' application... Furthermore, the occam process is the only
> process in the transputer...
>
> Why this difference? Thanks in Advance...
I can perhaps offer one suggestion; you are not comparing similar programs.
I know it sounds trivial, but in C you are using:
> void cycle(int iterations) {
>
> int i;
> for(i=0; i<iterations; i++) {
> /* nothing! */
> }
>
> }
whereas in occam you have:
> VAL INT iterations IS 10000000:
> SEQ
> clock ? time1
> i := 0
> WHILE ( i < iterations )
> SEQ
> -- nothing!
> i := i + 1
> clock ? time2
The C version holds `iterations' as a variable, whereas the occam program
has a constant. Large constants are (relatively) expensive on a transputer;
it is faster to load a local variable than to generate the
constant '10000000'.
Try changing the occam to something equivalent to the C:
PROC cycle(VAL INT iterations)
INT i :
SEQ
i := 0
WHILE i < iterations
i := i + 1
:
You will find that this is the entire reason for the change.
The D4205A compiler produces this for the version with the constant
value for `iterations':
0: 20 20 20 pfix 0
3: 60 BF ajw -1
5: 40 ldc 0
6: D0 stl 0
7: 29 28 29 26 28 40 ldc 10000000
13: 70 ldl 0
14: F9 gt
15: A5 cj 5
16: 70 ldl 0
17: 81 adc 1
18: D0 stl 0
19: 60 02 j -14
21: B1 ajw 1
22: 22 F0 ret
and this for the version where it is a formal parameter:
0: 60 BF ajw -1
2: 40 ldc 0
3: D0 stl 0
4: 72 ldl 2
5: 70 ldl 0
6: F9 gt
7: A5 cj 5
8: 70 ldl 0
9: 81 adc 1
10: D0 stl 0
11: 60 07 j -9
13: B1 ajw 1
14: 22 F0 ret
The same problem would occur in C if you used the constant in the for loop.
---
Conor O'Neill, Software Group, INMOS Ltd., UK.
UK: conor@inmos.co.uk US: conor@inmos.com
"It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads