Closed GoogleCodeExporter closed 9 years ago
Stack overrun (son of issue 37).
Guess we need 64MB.
Original comment by classi...@floodgap.com
on 29 May 2011 at 3:35
(summary change)
Original comment by classi...@floodgap.com
on 29 May 2011 at 3:36
Confirmed crash 4.0.2 on
http://krakenbenchmark.mozilla.org/kraken-1.1/driver.html.
Confirmed not crashing 4.0.2 with nanojit disabled. Here, benchmark runs
successfully to the end (some patience needed, though). Tested on G4 7450 with
reduced processor speed (667 MHz). Reached glorious 827764.3ms +/- 14.0%.
ulimit -s 65536 cannot be tested. "cannot modify limit: Operation not
permitted" for anything higher than 32768.
Original comment by chtru...@web.de
on 30 May 2011 at 3:23
It lets me do it, but I'm not sure if it stuck or if it works, because 4.0.2
still couldn't.
This is a real problem because 64MB is the maximum stack allocation on OS X --
there is no way to unlimit it like Linux. We may need to make the nanojit
detect if it's going to run off the end and abort if so, and I don't know how
to do that. Asking my contacts at Mozilla/Adobe if they have ideas.
We should try to fix this for 4.0.3 and 5. In the short term we'll run off 64MB
stack builds while I try to think of a permanent solution.
Original comment by classi...@floodgap.com
on 30 May 2011 at 4:08
Yeah, it just didn't stick with ulimit. With 64MB of stack Kraken does complete
on 5 beta 1. For comparison, on the quad G5 in highest,
===============================================
RESULTS (means and 95% confidence intervals)
-----------------------------------------------
Total: 31568.0ms +/- 0.5%
-----------------------------------------------
ai: 8305.0ms +/- 1.5%
astar: 8305.0ms +/- 1.5%
audio: 8222.0ms +/- 1.3%
beat-detection: 1303.9ms +/- 2.8%
dft: 1809.0ms +/- 0.7%
fft: 1041.2ms +/- 3.6%
oscillator: 4067.9ms +/- 1.6%
imaging: 10451.1ms +/- 0.2%
gaussian-blur: 3546.4ms +/- 0.2%
darkroom: 1304.0ms +/- 0.7%
desaturate: 5600.7ms +/- 0.2%
json: 471.5ms +/- 0.6%
parse-financial: 279.9ms +/- 0.7%
stringify-tinderbox: 191.6ms +/- 0.7%
stanford: 4118.4ms +/- 0.1%
crypto-aes: 1172.8ms +/- 0.4%
crypto-ccm: 1011.7ms +/- 0.3%
crypto-pbkdf2: 1417.6ms +/- 0.1%
crypto-sha256-iterative: 516.3ms +/- 0.2%
Rather better :)
Still, we need to deal with a low stack situation more gracefully, because we
won't be able to wallpaper anymore soon enough.
Original comment by classi...@floodgap.com
on 30 May 2011 at 6:03
Impressive. How come I can't set ulimit higher than 32768 on either my G3s nor
my G4 PowerBook? This might come in handy some day.
Original comment by chtru...@web.de
on 30 May 2011 at 6:14
I didn't, for this. I set it in the build script. So at least we can wallpaper
over 4.0.3 and 5b1 this way.
Original comment by classi...@floodgap.com
on 30 May 2011 at 6:16
Landed for 5. 4.0.3 presently.
Original comment by classi...@floodgap.com
on 2 Jun 2011 at 6:05
Kraken 1.1 runs successfully in TFF 5.0beta1 with nanojit enabled. Reached
113816.0ms +/- 9.2% on 667 MHz single core G4. This is more than 7 times faster
than without the jit.
Original comment by chtru...@web.de
on 3 Jun 2011 at 8:15
Landed in 4.0.3
Original comment by classi...@floodgap.com
on 19 Jun 2011 at 3:56
===============================================
RESULTS (means and 95% confidence intervals)
-----------------------------------------------
Total: 32211.3ms +/- 0.6%
-----------------------------------------------
ai: 8332.0ms +/- 1.3%
astar: 8332.0ms +/- 1.3%
audio: 8864.1ms +/- 2.2%
beat-detection: 1225.5ms +/- 0.6%
dft: 2480.5ms +/- 7.1%
fft: 1057.2ms +/- 1.0%
oscillator: 4100.9ms +/- 0.8%
imaging: 10260.5ms +/- 0.6%
gaussian-blur: 3356.1ms +/- 1.9%
darkroom: 1295.2ms +/- 0.5%
desaturate: 5609.2ms +/- 0.3%
json: 607.3ms +/- 0.3%
parse-financial: 398.6ms +/- 0.5%
stringify-tinderbox: 208.7ms +/- 0.6%
stanford: 4147.4ms +/- 0.2%
crypto-aes: 1176.4ms +/- 0.6%
crypto-ccm: 1032.4ms +/- 0.1%
crypto-pbkdf2: 1411.5ms +/- 0.2%
crypto-sha256-iterative: 527.1ms +/- 0.5%
VERIFIED (in 4.0.3 too)
Original comment by classi...@floodgap.com
on 19 Jun 2011 at 11:19
Original issue reported on code.google.com by
ePoL...@gmail.com
on 29 May 2011 at 3:31