Re: [dev-serveez] mandelbrot fractal server

[stefan]

On Mon, 12 Nov 2001, Raimund 'Raimi' Jacob wrote:

> I added --disable-shared and got a 800k serveez binary that was mostly
> statically linked:
> address@hidden:~/src/serveez/src > ldd serveez
>         libm.so.6 => /lib/libm.so.6 (0x4001b000)
>         libz.so.1 => /usr/lib/libz.so.1 (0x40038000)
>         libbz2.so.0 => /usr/lib/libbz2.so.0 (0x40047000)
>         libdl.so.2 => /lib/libdl.so.2 (0x40058000)
>         libc.so.6 => /lib/libc.so.6 (0x4005c000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> 
> (btw: at first serveez' ./configure refused to re-configure guile
>  (although, of course, the parameters changed). since i didnt know wich
>  file to delete, i had to delete the guile sources and start from the
>  beginning)

It's `libguile/scmconfig.h', thought it was a good one... any objections
here?

> > We could supply some `svz_sock_nagle (int state)' and export it to Guile.
> 
> that sounds good. that function is nice wether this solves the problem
> here or not. but i am not sure if i like the name... the algorithm used in
> the kernel is called 'nagle' but the sock option (as you stated) is
> TCP_NODELAY. mmh... dunno.

My suggestion now:

 * Provide `svz_tcp_nagle()' in `core.c' very likely `svz_tcp_cork()' in
   the Serveez API.
 * Provide `svz:sock:no-delay' inside Guile if it is a TCP socket.

> > Does Guile really free memory if possible?
> 
> i had a rather longish profiling run (300x300 mandelbrot, 1 client). the
> picture is really nice. however, the profiling information shows the
> following:
> 
> --- server ---
>  22.11     13.68    13.68  1532510     0.01     0.03  scm_ceval
>  14.16     22.44     8.76   143031     0.06     0.06  scm_gc_mark
>   8.92     27.96     5.52     1413     3.91     3.98  scm_gc_sweep
> 
> --- client ---
>  27.32     25.05    25.05     5421     4.62     4.64  scm_gc_sweep
>  18.74     42.23    17.18   540007     0.03     0.03  scm_gc_mark
>  17.90     58.64    16.41  1351166     0.01     0.06  scm_ceval
> 
> [all other methods show significantly less. the firs svz_* function is
>  at rank 4 and 9]
> 
> as we can see, all cpu is basically used for guile evaluation and garbage
> collection. unfortunately we cannot see any implicit or explicit sleeps
> (since we see no libc calls). also interesting: more "mark" than
> "sweep". Mark is probably recursive, perhaps sweep is delayed if possible
> (which would result in serveez mem consumption). anyway.

The Serveez memory consumption was mainly caused by memory leak inside
Serveez.  Sorry for this.  Just fixed it and put it to CVS.

> all % above are relative so we cannot see how mich actual time was wasted
> not computing. dont know where to look... we have to wait for de-nagled
> results...

Will follow soon... if you accept the above names.

Cheers,
        address@hidden