From: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH] Change setjmp/longjmp to
_setjmp/_longjmp to avoid overhead and fix signal masking bug
Date: Sat, 7 Jul 2012 22:04:32 +0200
> On Fri, Jun 15, 2012 at 12:45:28PM +0200, Felix wrote:
>> > Other than figuring that out, it would be
On Fri, Jun 15, 2012 at 12:45:28PM +0200, Felix wrote:
> > Other than figuring that out, it would be a good idea to test on mingw
> > and OS X (I was going to do this). However testing on other platforms
> > like cygwin or Solaris (or more obscure?) is problematic. It is not
> > really a question
> Other than figuring that out, it would be a good idea to test on mingw
> and OS X (I was going to do this). However testing on other platforms
> like cygwin or Solaris (or more obscure?) is problematic. It is not
> really a question of whether _setjmp works but if every platform supports
> _set
On Wed, Jun 13, 2012 at 08:34:14PM -0500, Jim Ursetto wrote:
> There won't be any improvement on Linux because _setjmp == setjmp;
Right.
> Linux doesn't save the signal mask on setjmp() unless the obscure __FAVOR_BSD
> is #defined. The performance regression you observed could just be
> statisti
Jim Ursetto scripsit:
> Peter mentioned to me that _setjmp is supported on Solaris but not on
> very old Solaris (like, 2.5).
I can't believe that anyone really cares about a 17-year-old release.
Backward compat is fine, but there need to be limits. Does current
Chicken build with gcc 2.7? It's
On Jun 13, 2012, at 8:51 PM, John Cowan wrote:
> On Cygwin, _setjmp and _longjmp are supported. I can test, but probably
> not until next week.
Cool, thanks. We can probably assume that if it compiles, it works fine.
> On Solaris, _setjmp and _longjmp don't manipulate the signal mask,
> wherea
Jim Ursetto scripsit:
> Other than figuring that out, it would be a good idea to test on mingw
> and OS X (I was going to do this). However testing on other platforms
> like cygwin or Solaris (or more obscure?) is problematic. It is not
> really a question of whether _setjmp works but if every p
On Jun 13, 2012, at 7:28 PM, Mario Domenech Goulart wrote:
> Unfortunately I could not observe any improvement on Linux x86. The
> performance is actually slightly worse with your patch (using master,
> c48a109d668f3186bb4a213940c0b0b81a1ad03d). I run the benchmarks with no
> csc options and wi
Hi Peter,
On Wed, 13 Jun 2012 23:22:02 +0200 Peter Bex wrote:
> I've also attached two outputs from the resurrected Chicken benchmarks
> by Mario: https://github.com/mario-goulart/chicken-benchmarks
> These clearly show about a 5% speed improvement across the board.
> (you can see a clear compar
Hi,
On Wed, 13 Jun 2012 23:22:02 +0200 Peter Bex wrote:
> I've also attached two outputs from the resurrected Chicken benchmarks
> by Mario: https://github.com/mario-goulart/chicken-benchmarks
> These clearly show about a 5% speed improvement across the board.
> (you can see a clear comparison b
Hi hackers,
While looking over a system call trace while debugging another issue,
I noticed a LOT of system calls to __sigprocmask14 (on NetBSD).
It turns out these are generated by setjmp() and longjmp(), so upon
each minor GC it make do two superfluous system calls. According
to POSIX, it is a
11 matches
Mail list logo
