freenode/#clasp - IRC Chatlog
Search
7:03:08
drmeister
I'm looking for it - it isn't in my local repo of ironclad (obviously out of date)
7:04:32
beach
I think if you could characterize what is special about that function, and then get some timing data, that would be a good start for improving compilation times. As opposed to guessing and improving parts that have only a marginal impact on performance.
7:05:42
beach
I am personally guessing (but I don't want my guess to be the basis if an attempt to improve it) that the way lexical compile-time environments are handled could be problematic, especially if your generic dispatch is not terribly efficient.
7:11:01
beach
Since dynamic extent is fishy, I am reluctant to include it in SICL until I know more about it.
7:11:33
beach
SBCL basically trusts the programmer's declaration, which would be unacceptable in SICL, for safety reasons.
7:12:49
drmeister
::notify Bike - One ironclad function (http://paste.lisp.org/display/350808) - takes a huge amount (2439 seconds) - the pass is mark-dynamic-extent (1818 seconds). The next function after that is only 259 seconds.
7:14:04
drmeister
We went on a big 18km hike today to an alpine lake - I'm very sore and tired - I'm off to bed.
11:51:36
Colleen
Bike: drmeister said 4 hours, 38 minutes ago: - One ironclad function (http://paste.lisp.org/display/350808) - takes a huge amount (2439 seconds) - the pass is mark-dynamic-extent (1818 seconds). The next function after that is only 259 seconds.
13:33:00
Bike
liveness spends 20% in member, 20% in union, 10% in set-difference. having an actual set implementation would fix that up, or as a more stopgap kind of thing i can speed those particular functions up a bit
13:53:33
Bike
so probably no magic bullet here. we could disable trying dynamic extent if it's useless, like here, but otherwise it basically amounts to "make clasp go faster"
13:59:34
Shinmera
Yeah but that's just around the threshold probably, so I don't know if it's a guaranteed win
14:01:07
Bike
let's see, assoc is a C++ function for whatever reason, that just takes test and test-not directly, and does some kind of "Tester" thing
14:20:02
Shinmera
Given that it's the most frequent comparison operator, inlining it seems fairly important
14:28:20
Bike
(loop for pair in list when (eql item (car pair)) return pair) is like 50% slower than a full call to assoc. ugh
14:44:25
Bike
i guess it's not that strange. all the little inefficiencies like boolean tests and such are going to be the main factor when i do something a million times
14:50:13
beach
The modular way of doing that is to use a hash table, but that's probably not going to be fast enough.
14:50:37
Bike
but performance is reasonable on sbcl. doing the same mark-dynamic-extent, it takes half a second for what takes clasp, uh, half an hour.
14:51:47
beach
Seriously, yes, it might be worthwhile trying to figure out why Clasp is this much slower in this case.
14:52:34
beach
Failing that, stealth mixins will give you both modularity and performance in case you want to number the data.
14:52:46
Bike
numbering data is probably good too, but after my misadventure with bit vectors i'm inclined to just stick with the apparently reasonable algorithms that i know work
14:53:27
beach
Like I said, it might be worthwhile trying to figure out why Clasp is this much slower.
14:54:57
Bike
because the loop was supposed to be what i'd inline assoc with no keyword arguments as.
14:55:57
Bike
i did have some success with other inlines. like, last few days i set it up so that map, coerce, and make-sequence with constant type argument deal with it at compile time, and hey, now they take half as long
14:57:45
beach
Sure. I am tired after a long day, so I am just generally meddling with your business. I am not restricting my discussion to Cleavir.
14:58:28
Bike
maybe i should try boolean elimination... that'll make a lot of inlines actually helpful
15:05:36
beach
Would it be a way to improve the dynamic extent calculation, or is this a different optimization to make things faster?
15:07:52
Bike
different. i'm thinking of how to make the lisp assoc faster than the C++ one. a faster assoc would help dx, but also, like, everything else.
15:08:37
beach
In general, it is possible to do a better job in Common Lisp than in C++ because you can special-case things with compiler macros etc.
15:15:47
beach
So ENDP needs to be something like (cond ((consp bla) nil) ((null bla) t) (t (error....))) no?
15:16:10
Bike
i added a definition to inline it as i said. for nonzero safety the THE will be turned into TYPEQ.
15:17:38
beach
Well, first you test the CONS tag, which is going to be true, but then it can be either a CONS or NIL, so you have to make a second test.
15:18:04
Bike
in this case i put on safety zero for testing's sake and it was still slower, even though that reduces (endp foo) to (eq nil foo). i guess because of booleans and such
15:18:07
beach
Or, you can test for NULL first. But that test is going to be false, so you have to test the CONS tag after that.
15:18:57
Shinmera
Testing for cons first seems better for branching anyway since it would succeed in most cases, right?