Re: [dev-serveez] mandelbrot fractal server

[Raimund 'Raimi' Jacob]

On Sun, 11 Nov 2001, stefan wrote:

hello again!


> On Sun, 11 Nov 2001, Raimund 'Raimi' Jacob wrote:
> > On Sat, 10 Nov 2001, stefan wrote:

> $ CFLAGS=-pg LDFLAGS=-pg ./configure --with-guile-source=/path/to/guile

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)

> 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.

> 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.

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...

Bye,
    Raimi

--
      __/\     _/\    _____/\.___/\
     /   /    /  /___/   ____/  __/\     Name    : Raimi
    /   /  __/    __/   / __/  / _\/     Contact : address@hidden
   /   /__/ /     \/   /_/_/  /_/        Visit   : http://www.lkcc.org
  /________/___/\._\._____/_____/\       3.141592653589793238462643383
  \._______\.__\/__/\.____\.____\/       27950288419716939937510582097