Re: gnubg-cli crash

[Murat K]

    Unless you will run as many cubeful games, I don't understand why
    you are running so many cubeless ones.
    
    The purpose of my last set of experiments was to see if the weaker
    player would win more or less in cubeful games as in cubeless ones
    against the same stronger player.
    
    The idea of wondering the skill difference between plies came up as
    a secondary curiosity because I was shocked to discover how little
    difference there was between 2-ply and 3-ply cube settings during
    my Experiment 15.
    
    Maybe you guys knew it all along but I didn't and I had expected
    bigger differences between ply levels.
    
    It looks like they had already figured that the difference between
    0-ply and 2-ply was about 65 Elo points or 0.052 ppg which the
    same as what you found between 0-ply and 3-ply.
    
    See: Re:
      [Bug-gnubg] How strong is the lookahead? (mail-archive.com)
    
    From these, it looks like there is no discernible difference between
    2-ply and 3-ply which sounds very strange to me but I don't know
    what to conclude from that. Perhaps some of you guys may make
    more sense out of it all?
    
    Instead of running more cubeless games, I would encourage you to
    run 50,000 cubeful games with 3-ply vs 0-ply
    checker settings and
    with the same cube level, perhaps 2-ply, for both sides to see how
    the cubeful vs cubeless results compare. (I run my comparisons
    using the same RNG and seed but with 50,000 trials it may not
    matter if you don't know the seeds you used for cubeless sessions.)
    
    MK

On 9/4/2024 1:35 AM, Ian Shaw wrote:

I don’t know how far I’ll pursue it, because I’m busy, but I ran 50000 games cubeless 3-ply v 0-ply.

 

3-ply 33400 0-ply 30817. 0-ply lost 0.052 ppg. Your results were 25656 – 13536 = 0.071 ppg over 20000 games.  Combining these 70000 games is 0.057 ppg.

 

This makes me think there are not enough samples, which isn’t surprising considering how good the bot is at 0-ply. Added search depth gives an improvement, but it is small.

 

• Ian

 

 

From: Murat K <playbg-rgb@yahoo.com>
Sent: Wednesday, September 4, 2024 6:13 AM
To: Ian Shaw <Ian.Shaw@riverauto.co.uk>; Philippe Michel <philippe.michel7@free.fr>
Cc: bug-gnubg@gnu.org
Subject: Re: gnubg-cli crash

 

Ian, are you doing experiments similar to mine? I would
be very curious to know what results you end up with?

With "record off" you can't save the session SGF, right?

Session analysis done on-the-go isn't accurate. You'll
need to clear and redo the session analysis which can't
be done without the session record, no? But maybe all
you want to know is points won/lost..?

MK

On 8/30/2024 3:52 AM, Ian Shaw wrote:

Hi Philippe, 

"set record off" solves the immediate  issue. After 12000 games the memory usages is stable at the initial value about 247 MB.

-----Original Message-----

From: Philippe Michel <philippe.michel7@free.fr> 

Sent: Tuesday, August 27, 2024 10:26 PM

To: Ian Shaw <Ian.Shaw@riverauto.co.uk>

Cc: bug-gnubg@gnu.org

Subject: Re: gnubg-cli crash

On Mon, Aug 26, 2024 at 08:47:39AM +0000, Ian Shaw wrote:

I'd been running a longish session of gnubg self-play when I got a crash. Is this a memory error?

gnubg 3-ply wins a gammon and 2 points.

The score (after 3428 games) is: gnubg 3-ply 2245, gnubg 0-ply 2183 (money session, without Jacoby rule).

Considering move...

(gnubg-cli:35568): GLib-ERROR **: 17:26:03.666: 

../glib-2.74.5/glib/gmem.c:136: failed to allocate 699016 bytes

Yes, this is a memory allocation error. Gnubg uses the GLib memory allocation functions and, from their documentation: "If any call to allocate memory using functions g_new(), g_new0(), g_renew(), g_malloc(), g_malloc0(), g_malloc0_n(), g_realloc(), and g_realloc_n() fails, the application is terminated."

The idea is that it is difficult to recover cleanly from such a condition and modern computers have so much memory that it will never happen :-).

Running a 35 games session, my process (on linux but it shouldn't matter

much) goes from 230M to 257M, so at 3428 you may have used about 230 +

100 * 27, or 3 GB. gnubg-cli.exe being a "large address aware" 32bits executable, it should be able to use 4 GB of memory on a 64bits OS but less than this on a 32bits one (see https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.microsoft.com_en-2Dus_windows_win32_memory_4-2Dgigabyte-2Dtuning&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=NIzIKF-gDHHkAFMi3cht7V4XuqIwZykq4ICAvAepvAo&m=iroh4KjxcqHjASFeE_4bcBo5AIKoY6D0O5QBK_fOJeGeX8evPpj6_TM6oBWEjXAe&s=nJ2kPo1VfqoEfIAQP20Mk8zejW30VMlZiEuKlR-DhRw&e=

for explanations).

Using about 500kB-1MB per game seems a bit high but not ridiculous (the evaluations of all legal moves in all positions are recorded). As far as I know there is no memory leak in the session recording but it may not be used as sparingly as it could.

As a practical matter, if you need to keep the games record you should probably restrain the sessions to, for instance, 2000 games and collate the results yourself if you need more of them.

If you don't need it you can use the "set record off" CLI command or uncheck "Settings/Options/Other/Record all games" in the GUI.