freenode/#clasp - IRC Chatlog
Search
22:22:31
Bike
ok, got ctors into a usable state and testing them. on clasp, the time to make ten thousand instances goes from 0.263 s to 0.042 s. about 6.26 times faster, which is kind of spooky since i got 6.26 for sbcl's ctors as well, but whatever
22:29:18
Bike
it's not as good as it could be, and it'll still do generic dispatch for slot-bound/value-using-class in the initializer, so it'll be worse with slots, but at least i'm not completely wasting my time
22:35:56
Shinmera
Computing applicable initargs requires scanning all applicable methods' arglists and all, so I'm not too surprised.
22:36:49
Shinmera
Don't forget that &allow-other-keys in any of the methods means all initargs are allowed.
23:08:56
drmeister
I think we are using APPLY because we thought we had to pass the original arguments along with the whatever was passed to call-next-method, if call-next-method was called with arguments,.
23:09:45
drmeister
Also, using APPLY means that more arguments can be passed in registers. But since we pass arguments and next-methods explicitly we only have two left on X86-64
23:14:09
Bike
okay, so the make-method-lambda page actually says it should return a function of two arguments
23:17:33
Bike
surely you can turn (lambda (...params...) ...body...) into (lambda (args next-methods) (flet ((call-next-method (&rest new-args) (funcall (car next-methods) (or new-args args) (cdr next-methods)))) (destructuring-bind (...params...) ...body)))) plus declarations and crap
23:24:10
drmeister
So the plus side is we don't need to use APPLY and the only downside is that argument access has to go through va_arg.
23:27:04
drmeister
If we pass the arguments using (funcall method args next-methods) then for method to access the arguments it has to use the va_arg macro.
23:28:01
drmeister
With (apply method args next-methods arg0 arg1 arg2 ... ) arg0 and arg1 will be passed in a register and arg2 and those that follow are passed on the stack.
23:28:40
drmeister
Currently setting up the registers and the stack is not done well at all - but it could be done better.
2:04:00
Bike
https://github.com/Bike/static-gfs aight. This should load in cclasp. anyone wants to fuzz it that would be swell.
3:28:39
beach
It sounded like you are working on it, but it would be very interesting to know what part of the execution time of a typical program is spent calling MAKE-INSTANCE. Or, equivalently, what the total performance improvement for a typical program is with this improvement.
3:36:57
Bike
yeah, i should find a library to test with (probably not cleavir, just because it's big for a starting point)
3:40:38
Bike
if it's just, run some long computation with the optimization and without, that's pretty easy to measure.
3:41:25
beach
Notice, though, that if you do it that way, presumably using Clasp, you might get a pessimistic figure.
3:42:01
beach
Because the rest of the computation is slower than it would be (or will be if you like) because Clasp is not yet highly optimized.
3:44:34
beach
OK, suppose that Clasp is 50 times slower than some highly optimized implementation such as SBCL. Also suppose all the additional time is spent in computations not related to MAKE-INSTANCE. Now suppose you measure that Clasp spends 5% of its time in MAKE-INSTANCE without ctors. You will conclude that the ctor optimization will improve performance by 4% or so.
3:45:32
beach
Now suppose Clasp is improved so that it becomes 50 times as fast. Without the ctor optimization, it would then spend half its time in MAKE-INSTANCE, and the ctor improvement would be very significant indeed.
3:47:10
beach
The best measure would be to figure out how much some typical programs spend in MAKE-INSTANCE when they run in a highly-optimized implementation such as SBCL.
3:48:10
beach
It would be the best indicator of the ultimate performance improvement resulting from your ctor implementation.
3:50:37
beach
I wonder whether it would be possible to just redefine CL:MAKE-INSTANCE to call the old one and then to profile the new one.
3:51:43
beach
(let ((old (fdefinition 'make-instance))) (setf (fdefinition 'make-instance) (lambda (&rest args) (apply old args))))
3:53:40
Bike
i think the reason you can't profile/trace/whatever built in functions is because the obvious way to do that is replacing the function definition, and that could cause issues.
3:53:56
Bike
or, like, in make instance's case, that doesn't do you any good if you don't inhibit compiler transformations
3:59:46
beach
So, one would have to :SHADOW #:make-instance in the entire application, and then do (defun make-instance (&rest args) (apply #'cl:make-instance args))
4:01:18
beach
I guess that would be possible with an application that has few packages. I am thinking of McCLIM. In the CLIM-INTERNALS package it might be possible to do that.
4:06:34
beach
There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION COMMON-LISP:COMPUTE-APPLICABLE-METHODS (1)> when called with arguments (#<CLOSURE (LAMBDA (&REST ARGS)) {100EF2C18B}> (#<STANDARD-CLASS SICL-EXTRINSIC-ENVIRONMENT:ENVIRONMENT>)).
4:07:07
beach
It appears that COMPUTE-APPLICABLE-METHODS is applied to the function definition of the symbol MAKE-INSTANCE.
4:09:33
Bike
i'm also a bit worried because the ctor thing is definitely not thread safe, and it's not obvious how it needs to include that
4:18:30
Bike
though i guess that's more like a general problem with e.g. a class being redefined in the middle of someone else shared-initializing one