freenode/lisp - IRC Chatlog
Search
0:47:09
nyef
The logand version only works for a power-of-two-minus-one, but is also far, far more likely to trigger compiler optimizations.
0:47:42
nyef
... And LOGAND operates in terms of integers, while MOD operates in terms of non-complex ("real") numbers.
0:51:06
mrottenkolber
porting CAS based queue algorithms to CCL for experimenting with Erlangen, possibly to find out that ccl::conditional-store has issues, then trying to work on that?
1:18:29
aeth
(defun foo (x y) (declare (integer x y)) (mod (+ x y) (1+ 255))) (defun foo* (x y) (declare (integer x y)) (logand #xff (+ x y)))
1:19:16
nyef
SBCL probably has an integer-division-by-power-of-2-strength-reduction transform, and from there the modular arithmetic optimizations would kick in.
1:21:19
aeth
SBCL actually doesn't have all the clever little micro-optimizations that can be done with parts of the CL language. It's fast but CL can definitely be made to be much faster.
1:22:18
nyef
Mmm. I've added some cleverness to SBCL myself, and I know of a couple of places where it isn't particularly excellent in terms of optimization.
1:24:25
aeth
Well, one thing that was talked about a few weeks ago is (remove-if-not #'foo ...) vs. (remove-if (complement #'foo) ...) being different, rather than having the equivalent disassembly that many assume. I'm not sure if that's possible, though.
1:25:48
nyef
For them to be fully equivalent in terms of code generated, I'd expect remove-if-not and complement to be open-coded, and I don't know that they are.
1:26:17
aeth
I suppose it would have to be done in all possible foo-not functions that are deprecated (or is only remove-if-not deprecated?)
1:26:21
mrottenkolber
does anyone have a copy of "Efficient Hardware Arithmetic in Common Lisp", http://jcsu.jesus.cam.ac.uk/~csr21/papers/modular/modular.pdf seems down
1:28:15
aeth
I think all the foo-if-not functions are deprecated. It looks like there are twelve of them: http://l1sp.org/search?q=%2Dif%2Dnot
2:53:41
loke
aeth: Yeah, that'll never happen. :-) And even if it did, there is no way the *-if-not functions would be removed.
3:48:37
edgar-rft
loke: what exactly is the difference between "no new standard coming ever" and "infinite time between CL standards"? To me both seems to be the same.
4:04:34
Bike
but time is continuous. but quantum mechanics says it isn't. but special relativity says the concept of a time between events is difficult. but bla bla bla
4:35:56
nyef
... Which some quick digging shows to be a bullshit concept not associated with anything "real".
4:41:01
Bike
i never had quantum and i barely had relativity in school, so i'm basically chopra level
5:36:16
drmeister
So I ran into a fundamental flaw in Linux and OS X wrt integrating C++ and Common Lisp.
5:36:45
drmeister
It doesn't appear to be possible to integrate unix signal handlers with C++ exception handling.
5:38:47
drmeister
When interrupting a thread - there are times when it needs to unwind the stack from the interrupt hander up to a level outside of the interrupt handler.
5:40:12
White_Flame
I presume unwinds when Clasp conditions are raised are implemented with C++ exceptions?
5:40:37
White_Flame
I remember back in my C++ days, exceptions were very brittle when it comes to OS integration
5:40:43
drmeister
Yes, all unwinds are C++ exceptions. It's the only way to work with RAII and call destructors properly.
5:45:02
drmeister
That was a bad timedwait calculation. I fixed that and then had a 75% CPU usage because of inefficiencies in Clasp and Slime.
5:45:31
drmeister
stassats "fixed" Slime so that it doesn't poll a condition-variable every 0.2 seconds and I fixed some stuff in Clasp.
5:46:36
drmeister
Sadly though C-c C-c and M-C-x stopped working because Clasp doesn't do interrupt-process properly because I stalled in implementing it when I realized that signal handlers and C++ exceptions were incompatible.
5:47:49
drmeister
Thinking about it though. If an error happens in Clasp, sldb will come up and that doesn't involve interrupting the thread. In that case there is no problem with restarts or unwinding the stack.
5:52:47
drmeister
Control-c could interrupt a loop and bring up sldb - but I can't unwind the stack out of the interrupt handler.
5:54:11
drmeister
I could set a thread local flag that says 'Control-c was hit' and insert a poll in every loop that I want to Control-c out of. That will be tedious - but I don't see any other way.
5:55:43
drmeister
Yes - but calling destructors properly between the interrupt handler and wherever I want to return to is the thing I can't do.
5:58:13
drmeister
I'm tossing this out there in case anyone else has any ideas. I'd love to hear them.
6:09:14
jackdaniel
drmeister: you may have signal servicing thread which handles signals scheduled by an actual handler (which returns as fast as it can)
6:09:44
jackdaniel
in that case you are not in this very sensitive context and exceptions shouldn't interfer too much
8:06:03
flip214
hmmm, the lotto example from http://www.xach.com/naggum/articles/3063147946409477@naggum.no.html is with gcc -O3 more than twice as fast as with SBCL 1.3.14...
11:44:42
drmeister
jackdaniel: My problem is this common scenario: A process is running and taking too long. I hit Control-C and a SIGINT gets sent to the process with an interrupt handler that calls #'break. sldb comes up and lets me inspect things. I decide I want to unwind the stack to above the loop that was taking too long.
11:47:17
jackdaniel
drmeister: in handler you may save, which thread is to be interrupted, and interrupt it from signal handler thread
11:49:01
flip214
so perhaps you'll need to "inject" calling some cleanup-code, that cleans up the caller chain
11:58:40
ogamita
or any other non-local exit destination: a block with a closure to return to it, a catch with an object to throw at, a handler with a condition to signal to.
11:59:56
ogamita
drmeister: sigint can be distributed to any thread by default. If another thread is interrupted, you will have to "go over" the thread you want to debug. Take this into account.
12:05:52
drmeister
I can't unwind to a restart established around the loop from an interrupt handler. It has no way to properly unwind the stack and call destructors when interrupting execution at an arbitrary point.
12:06:14
drmeister
It's a fundamental incompatibility between C++ exception handling and unix signal handler.s
12:07:33
flip214
drmeister: to interrupt a thread, set its instruction pointer to a cleanup function that knows how to unwind the stack frames.
12:08:15
flip214
as you generate the code, you can control whether there's a frame pointer to help you, for example.
12:09:47
drmeister
The only way I see to deal with this is from within the interrupt handler, maintain a thread-local queue that is polled from within the loop from a safe-point, and then from the safe-point unwind the stack. It means I need to insert safe points into loops somehow.
12:12:37
drmeister
flip214: This is what I'm saying, there is no cleanup function that knows how to unwind the stack frames. Unwinding the stack in C++ is a very delicate process. It only happens from 'invoke' instructions that are like 'call' but have a second return path that goes through 'landing-pads' that know how to call destructors and unwind the stack. This is how
12:14:57
drmeister
Interrupting a thread means that after any arbitrary instruction, an interrupt can come in and the stack can be taken over by the interrupt handler. Things can be set up so that the interrupt handler returns to the next instruction, but there is no way to unwind to a frame above that because there is no way to identify an appropriate landing pad to start
12:16:25
flip214
well, how about just _killing_ the thread and running the cleanup fns in another (newly created) thread?
12:20:16
ogamita
drmeister: I don't understand why there would be an incompatibility between unix signal handlers and C++ exception handling.
12:21:05
ogamita
drmeister: Also, if you handle the signal in a specific thread, you reduce the problem to some thread-thread communication.
12:26:20
ogamita
Given the restrictions on what you can do in a signal handler, this thread would be a trampoline to dispatch and process signals.
12:27:03
jackdaniel
shka: check out src/c/unixint.d comment at the top if you are interested in details
12:46:13
drmeister
Thanks everyone for the feedback. I've been mulling this over and reading up on it for a week. I just wanted to get some input from lispers on it.