Re: [Fwd: Re: First look at new g-wrap -- it's slow!]

[Andreas Rottmann]

Andy Wingo <address@hidden> writes:

> On Wed, 2004-05-12 at 09:31, Andy Wingo wrote:
>> I took a first look at the new g-wrap. Yes I know I've been a bit
>> derelict. Oh well. Here are my thoughts and concerns.
>
> I think the "Send" button in my mail client makes me think less before
> and more after ;)
>
[making <gw-value> an instance of <gw-type>]

I already thought about wether this would be possible, but given my
relative little experience with metaclasses, I've not given it a shot
yet.

[hierarchy changes]

I'll definitly give this a go.

> Regarding the dual-namespace issue: The set of dependencies for a
> wrapset is known when the wrapset is derived. Why not just make
> #:dependencies take a kwarg, like
>
>  (define-class <miscutils-wrapset> (<gw-guile-wrapset>)
>     #:dependencies (list <gw-standard-wrapset>))
>
Good idea; this would then work similiar to the #:language and #:types
warpset class options.

> Takes care of depends-on! and the dual namespaces in one step. No more
> registry. Or if you don't like lists or quasi-quote you could do it like
> define-module does, with `#:use-wrapset <foo> #:use-wrapset <bar>' or
> something.
>
I think class arguments are resolved at definition time, so you'd get
'undefined symbol <foo>', I think. The registry however serves some
other purposes:

1) Assign a unique symbol to each wrapset independently of the class
   name; this is used e.g. for the name of the shared library.

2) Instanciate a given wrapset just once; e.g. when one has wrapsets
   A, B and C, both B and C depend on A. When you now create wrappers
   for B and C from the same program, A will only be instanciated
   once, instead of twice. I know we don't use this yet (only one
   wrapset generated by per guile invocation), but it might come handy
   performance-wise.

> The new code makes (gnome gtk) load slower for me (~13s vs ~10s), and
> also defines about 1000 more symbols, about 65 more with the <gtk-
> prefix. The numerical difference is probably due to gtk 2.4 vs 2.2.
> Damn. I was expecting it to load up in less time.
>
Probably the additional slowness is because of the higher number of
symbols. Seems Guile just doesn't scale in that regard.

Other than that, G-Wrap TNG has two "modes", the more tradiditional
one, where it will create a C wrapper functions, and the one where it
uses libffi. In libffi mode, the C runtime has more information
available and can thus (assumingly) create the generics a bit faster
in a loop. You can switch the mode by toggling

(define-class <gw-rti-wrapset> (<gw-wrapset>)
  (c-info-sym #:getter c-info-sym #:init-form (gen-c-tmp "c_info"))
  (function-rti? #:getter function-rti?
                 #:init-keyword #:function-rti?
                 #:init-value #t))
                             ^^^
that value in rti.scm.

> I tried to profile it but I don't have a working copy of guile's
> sources to compile with profiling. I then compiled it (and the new
> g-wrap) with -O3, which died after about 13 minutes of compilation
> with gcc-3.3. Instead of dying nicely, gcc-3.2 was oom-killed. Tried
> again with -O2. Same. Tried with -O. It worked, but with no
> performance improvement.
>
Could you check which mode you used? You can easily do so by looking
at the generated .scm files; they will contain lots of
%gw:procedure->method-public calls if they were created in traditional
mode; also the generated .c file will be huge (> 100K lines).

> Moral of the story: -O doesn't help. Profiling would help, but you
> need an instrumented guile to do that. What's wrong? What does your
> performance difference look like?
>
I'm just compiling an 0.5.3, so I can compare.

> Is it just that the bottleneck is the
> same (add-method!)?
>
The most time is still spent in add-method, altough using Guile 1.7
(IIRC) helps and libffi mode help a bit.

> Now, to the nits:
>
> In the docs you give the example, (generate-wrapset guile 'my-wrapset
> "my-wrapset"). Why is there a need for a secondary namespace of
> wrapsets? Wouldn't (generate-wrapset <my-wrapset> "my-wrapset") suffice?
> Same with depends-on!.
>
See my comments above on the registry.

> Also, I think depends-on! is a bad name, because it doesn't include a
> verb. If you do an apropos on "!", you'll find all of those procedures
> include a verb. Perhaps add-dependency! or something would be good. I
> even like ws-add-dependency! better. More about generics in an email to
> guile-user.
>
Agreed, altough one can do away completely with this method, as you
said.

> Another thing I don't understand is, when defining new types, why do you
> have to derive a class, then instantiate the derived class? Is this to
> get around GOOPS' lack of class methods?
>
> I think the type parameter of the unwrap-value-cg and wrap-value-cg
> methods should be a <timespec64-type>. Also the second unwrap-value-cg
> should be wrap-value-cg. I think you were sleepy when you wrote those ;)
>
> Regarding the C output: it's difficult to read. Perhaps it should be run
> through indent if indent is available. Dunno.
>
Agreed; that might be good idea.

> Another C issue: Why do functions need any prefix other than _wrapper? I
> see the need from a generality perspective, but even the current method
> isn't foolproof -- the only way to be completely general is to allow the
> user to specify the name of the c wrapper herself. Python does it this
> way.
>
You mean why wrapper functions are named gw__tmpXXX_FOOBAR_wrapper?
Why do yu have a problem with that?

> Your scheme modules in general need a couple-sentence commentary at the
> top. For example, it took me a while of poking around to figure out what
> rti means. A short sentence or two would orient the reader as to what
> the file is trying to do.
>
ACK.

> Is it possibile to include this code in our tarball via arch
> multi-projects? It's appealing in light of the 2.8 bindings process, and
> the slowness of g-wrap releases.
>
Yes, I think this actually is a great idea; I'll look into this shortly.

> In the docs: the C values that need _destruction_, not deconstruction, I
> think. Also, shouldn't it be destroy-value-cg instead of
> destruct-value-cg?
>
Yep, destroy is probably a better name.

> One of the g-wrap tests fails: "output arguments work as advertised"
>
I have a fix for this ready -- output arguments only work in
traditional mode, yet.

> OK. It looks good, but the lack of class methods, the dual namespaces,
> and performance problems really are problems. What can we do to fix
> those? 
>
The performance issue is a bad one. Guile 1.7 makes this quite a bit
better IIRC (when I tuned the stuff, I used 1.7), but there is not
much we can do about it.

> And in the meantime, can we / should we use it in guile-gnome?
>
We can, as proven by the split modules, which already *depend* on
G-Wrap TNG :-p. I think we should, too. Output and defaults arguments
are a good reason IMHO.


Cheers, Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Python is executable pseudocode, Perl is executable line-noise.