From: Faré <fa...@gm...> - 2012-11-19 15:05:36
|
Dear SBCL hackers, is there a way, beside actually calling the function, to force SBCL to pre-compile the bits of code associated with method definitions? Currently, we have a significant pause during our first request while SBCL spends time in the compiler to do something compiling methods. Our workaround is to call the most significant functions once before we dump an image, but it's somewhat ugly. Is there a better way? We tried, to no avail, some old and new tricks that were suggested: 1- (sb-pcl::precompile-random-code-segments) 2- (setf (sb-pcl::gf-precompute-dfun-and-emf-p (sb-pcl::gf-arg-info gf)) t) (sb-mop:set-funcallable-instance-function gf (sb-pcl::compute-discriminating-function gf)) Does any SB-PCL hacker have suggestions on how to do it right? (Currently using a relatively recent SBCL 1.1.0.x, but can upgrade if necessary.) —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Guns & bullets don't kill people — blood loss and organ damage kills people. |
From: Paul K. <pv...@pv...> - 2012-11-19 15:11:58
|
On 2012-11-19, at 10:04 AM, Faré <fa...@gm...> wrote: > Dear SBCL hackers, > > is there a way, beside actually calling the function, to force SBCL to > pre-compile the bits of code associated with method definitions? > Currently, we have a significant pause during our first request while > SBCL spends time in the compiler to do something compiling methods. In the general case (with degenerate enough class structure and method specialisations), I don't think it's practical. For a lot of practical cases, however, I believe it's possible to design something that degrades as gracefully as the current scheme. What's the shape of the inheritance graph like? How many methods are there per gf, and how are they specialised? Any fancy method combination (less important than it might seem, because the MOP is already twisted for arbitrary combinations)? Paul Khuong |
From: Douglas K. <do...@go...> - 2012-11-19 16:38:50
|
This is in specific reference to the 'serialize-object' method in cl-protobuf. One GF with a thousand or primary methods. On Mon, Nov 19, 2012 at 10:11 AM, Paul Khuong <pv...@pv...> wrote: > On 2012-11-19, at 10:04 AM, Faré <fa...@gm...> wrote: > > > Dear SBCL hackers, > > > > is there a way, beside actually calling the function, to force SBCL to > > pre-compile the bits of code associated with method definitions? > > Currently, we have a significant pause during our first request while > > SBCL spends time in the compiler to do something compiling methods. > > In the general case (with degenerate enough class structure and method > specialisations), I don't think it's practical. For a lot of practical > cases, however, I believe it's possible to design something that degrades > as gracefully as the current scheme. > > What's the shape of the inheritance graph like? How many methods are there > per gf, and how are they specialised? Any fancy method combination (less > important than it might seem, because the MOP is already twisted for > arbitrary combinations)? > > Paul Khuong > > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |
From: Christophe R. <cs...@ca...> - 2012-11-19 16:45:42
|
Paul Khuong <pv...@pv...> writes: > On 2012-11-19, at 10:04 AM, Faré <fa...@gm...> wrote: > >> Dear SBCL hackers, >> >> is there a way, beside actually calling the function, to force SBCL to >> pre-compile the bits of code associated with method definitions? >> Currently, we have a significant pause during our first request while >> SBCL spends time in the compiler to do something compiling methods. > > In the general case (with degenerate enough class structure and method > specialisations), I don't think it's practical. For a lot of practical > cases, however, I believe it's possible to design something that > degrades as gracefully as the current scheme. Bah, and I just sent Faré an implementation of precompiling for all possible combinations of arguments, thinking "this might be material for a blog post! That counts as publication, right?" > What's the shape of the inheritance graph like? How many methods are > there per gf, and how are they specialised? Any fancy method > combination (less important than it might seem, because the MOP is > already twisted for arbitrary combinations)? I'm not sure that method combination is relevant, is it? Or if it is it's truly an edge case. What might be of immediate practical interest too is a simple function that introspects the current state of a gf's cache / dfun state and emits code that reconstructs it, so that once you've warmed up your application by running it on some representative data, you can compile a file containing e.g. (precompile-gfs #'foo #'bar) and the resulting fasl when loaded will populate the caches of #'foo and #'bar to be what they were when the form was compiled. Cheers, Christophe |
From: Faré <fa...@gm...> - 2012-11-19 18:50:44
|
On Mon, Nov 19, 2012 at 11:45 AM, Christophe Rhodes <cs...@ca...> wrote: > Bah, and I just sent Faré an implementation of precompiling for all > possible combinations of arguments, thinking "this might be material for > a blog post! That counts as publication, right?" > Thanks a lot! I will test it and report how well it works for us. > What might be of immediate practical interest > too is a simple function that introspects the current state of a gf's > cache / dfun state and emits code that reconstructs it, so that once > you've warmed up your application by running it on some representative > data, you can compile a file containing e.g. > (precompile-gfs #'foo #'bar) > and the resulting fasl when loaded will populate the caches of #'foo and > #'bar to be what they were when the form was compiled. > That would be great, as long as it still works when the code changes, i.e. it extracts a list of method names with combination of argument classes to specialize on, and does the precompilation using the code in the loading image, in those cases if they still apply in the loading image, rather than splice in the precompiled code from the fasl-writing image. At least, such a safe recompilation should be the default setting. To me, extracting the list or relevant methods and argument classes, so it can be dumped and a precompilation function may be explicitly called on it would be more satisfactory than any low-level code-splicing hack — auditing the list would also be an interesting use of this extraction, beside the optimization itself. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It's not ignorance that does so much damage; it's knowing so darned much that ain't so. — Josh Billings |