Guys,
I'm both impressed and horrified by the story.
The good news is that a problem is realized, analyzed and fixed for
some platforms - KUDOS!!
The not so news is that (a) why exactly THIS problem? (b) yet another
piece of assembler stuff, and (c) I got overflow both in my maildrop
and my own mail processing capabilities ;-)
When it comes to the first, then I have the following figures
comparing (running on a 1GHz Athlon):
2.95.3
kost (283) ./ozbench
nrev:
times (ms): t:305.71 r:0.0 g:0.0 c:0.0 p:0.0 s:50.28*
tak_normal:
times (ms): t:38.20 r:0.0 g:0.0 c:0.0 p:0.0 s:2.95*
tak_thread:
times (ms): t:114.19 r:0.0 g:0.0 c:0.0 p:0.0 s:5.80*
fd_simple:
times (ms): t:25.93 r:0.0 g:0.0 c:0.0 p:0.0 s:0.20
compiler_simple:
times (ms): t:47.33 r:0.0 g:0.0 c:0.0 p:0.0 s:2.0*
differentiate:
times (ms): t:462.0 r:0.0 g:0.0 c:0.0 p:0.0 s:44.0*
knights:
times (ms): t:292.57 r:0.0 g:0.0 c:0.0 p:0.0 s:38.28*
bridge:
times (ms): t:103.29 r:0.0 g:0.0 c:0.0 p:0.0 s:7.41*
port:
times (ms): t:285.0 r:0.0 g:0.0 c:0.0 p:0.0 s:20.75*
rec_normal:
times (ms): t:206.59 r:0.0 g:0.0 c:0.0 p:0.0 s:0.0
kost (284) ./ozbench
nrev:
times (ms): t:309.71 r:0.0 g:0.0 c:0.0 p:0.0 s:46.57*
tak_normal:
times (ms): t:38.23 r:0.0 g:0.0 c:0.0 p:0.0 s:2.90*
tak_thread:
times (ms): t:114.72 r:0.0 g:0.0 c:0.0 p:0.0 s:8.0*
fd_simple:
times (ms): t:26.14 r:0.0 g:0.0 c:0.0 p:0.0 s:0.41
compiler_simple:
times (ms): t:47.17 r:0.0 g:0.0 c:0.0 p:0.0 s:2.0*
differentiate:
times (ms): t:453.60 r:0.0 g:0.0 c:0.0 p:0.0 s:33.60*
knights:
times (ms): t:289.71 r:0.0 g:0.0 c:0.0 p:0.0 s:42.28*
bridge:
times (ms): t:103.61 r:0.0 g:0.0 c:0.0 p:0.0 s:7.4*
port:
times (ms): t:288.25 r:0.0 g:0.0 c:0.0 p:0.0 s:26.75*
rec_normal:
times (ms): t:206.59 r:0.0 g:0.0 c:0.0 p:0.0 s:0.0
kost (285) ./ozbench
nrev:
times (ms): t:307.14 r:0.0 g:0.0 c:0.0 p:0.0 s:49.42*
tak_normal:
times (ms): t:39.29 r:0.0 g:0.0 c:0.0 p:0.0 s:2.35*
tak_thread:
times (ms): t:113.76 r:0.0 g:0.0 c:0.0 p:0.0 s:7.17*
fd_simple:
times (ms): t:26.2 r:0.0 g:0.0 c:0.0 p:0.0 s:0.38
compiler_simple:
times (ms): t:47.14 r:0.0 g:0.0 c:0.0 p:0.0 s:2.9*
differentiate:
times (ms): t:461.60 r:0.0 g:0.0 c:0.0 p:0.0 s:43.60*
knights:
times (ms): t:312.66* r:0.0 g:0.0 c:0.0 p:0.0 s:37.0*
bridge:
times (ms): t:103.42 r:0.0 g:0.0 c:0.0 p:0.0 s:5.90*
port:
times (ms): t:287.42 r:0.0 g:0.0 c:0.0 p:0.0 s:23.71*
rec_normal:
times (ms): t:206.19 r:0.0 g:0.0 c:0.0 p:0.0 s:0.0
gcc 3.3.2
kost (67) ./ozbench
nrev:
times (ms): t:396.0 r:0.0 g:0.0 c:0.0 p:0.0 s:60.66*
tak_normal:
times (ms): t:49.80 r:0.0 g:0.0 c:0.0 p:0.0 s:2.73*
tak_thread:
times (ms): t:113.5 r:0.0 g:0.0 c:0.0 p:0.0 s:6.94*
fd_simple:
times (ms): t:26.31 r:0.0 g:0.0 c:0.0 p:0.0 s:0.43
compiler_simple:
times (ms): t:49.17 r:0.0 g:0.0 c:0.0 p:0.0 s:2.23*
differentiate:
times (ms): t:587.0 r:0.0 g:0.0 c:0.0 p:0.0 s:31.0*
knights:
times (ms): t:276.66 r:0.0 g:0.0 c:0.0 p:0.0 s:39.33*
bridge:
times (ms): t:102.95 r:0.0 g:0.0 c:0.0 p:0.0 s:9.90*
port:
times (ms): t:267.50 r:0.0 g:0.0 c:0.0 p:0.0 s:29.50*
rec_normal:
times (ms): t:294.28 r:0.0 g:0.0 c:0.0 p:0.0 s:0.0
kost (68) ./ozbench
nrev:
times (ms): t:395.0 r:0.0 g:0.0 c:0.0 p:0.0 s:61.33*
tak_normal:
times (ms): t:49.80 r:0.0 g:0.0 c:0.0 p:0.0 s:2.58*
tak_thread:
times (ms): t:114.10 r:0.0 g:0.0 c:0.0 p:0.0 s:5.78*
fd_simple:
times (ms): t:26.23 r:0.0 g:0.0 c:0.0 p:0.0 s:0.32
compiler_simple:
times (ms): t:49.26 r:0.0 g:0.0 c:0.0 p:0.0 s:2.10*
differentiate:
times (ms): t:583.0 r:0.0 g:0.0 c:0.0 p:0.0 s:39.50*
knights:
times (ms): t:288.25 r:0.0 g:0.0 c:0.0 p:0.0 s:33.75*
bridge:
times (ms): t:103.36 r:0.0 g:0.0 c:0.0 p:0.0 s:10.94*
port:
times (ms): t:268.0 r:0.0 g:0.0 c:0.0 p:0.0 s:30.25*
rec_normal:
times (ms): t:294.85 r:0.0 g:0.0 c:0.0 p:0.0 s:0.0
kost (69) ./ozbench
nrev:
times (ms): t:396.0 r:0.0 g:0.0 c:0.0 p:0.0 s:48.66*
tak_normal:
times (ms): t:50.0 r:0.0 g:0.0 c:0.0 p:0.0 s:2.87*
tak_thread:
times (ms): t:112.47 r:0.0 g:0.0 c:0.0 p:0.0 s:5.88*
fd_simple:
times (ms): t:26.27 r:0.0 g:0.0 c:0.0 p:0.0 s:0.43
compiler_simple:
times (ms): t:49.87 r:0.0 g:0.0 c:0.0 p:0.0 s:2.75*
differentiate:
times (ms): t:580.0 r:0.0 g:0.0 c:0.0 p:0.0 s:38.50*
knights:
times (ms): t:283.25 r:0.0 g:0.0 c:0.0 p:0.0 s:37.50*
bridge:
times (ms): t:102.76 r:0.0 g:0.0 c:0.0 p:0.0 s:10.0*
port:
times (ms): t:268.75 r:0.0 g:0.0 c:0.0 p:0.0 s:22.25*
rec_normal:
times (ms): t:294.85 r:0.0 g:0.0 c:0.0 p:0.0 s:0.0
This sounds more important. To say the least.
Anyone to confirm and/or comment??!
And when it comes to the second, I got an idea yesterday: why cann't
we calculate the entries in the 'instrTable' from the entries in
'fakeInstrTable'? That is, the code would still look like
L8948: # fake POPEX
#APP
.align 16
.long 109
.align 16
#NO_APP
# NO labels, both implicit (assembler) and explicit (C++) here:
movl am+36,%eax
addl $4,%ebp
addl $-24,(%eax)
jmp *(%ebp)
and the 'configure' script would calculate the offsets between the
"fake" and a "real" label, should it be there.
As far as I can see, as long as the current method works this one will
work too.
Cheers,
--- Kostja.
.ps Oh yeah - THANK YOU Denys VERY MUCH for fixing the dictionary bug!!!
I have a feeling that someone already had a RELATED complaint but
at the time there was not somehow enough material to work with
(e.g. it was not reproducible). Amazing how the whole thing still
worked for real big applications. Ergh, shame on me..
-
Please send submissions to hackers@mozart-oz.org
and administriva mail to hackers-request@mozart-oz.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.