niess at ma.tum.de
Fri Jan 13 01:03:15 EST 2012
Thank you for your help! I use gcc and pthread and on one computer linux
but on the other unix (or even old-aged solaris) - is this a problem?
Have I understood correctly that I can still invoke nauty again and
again in a thread, just not at the same time, running somehow parallel?
I would not be able to do the latter, anyway, but I need to use nauty
several times. Unfortunately, I don't know Perl. Can I just use mkts
like a bash script or do I have to do or to install something else? I
hope the performance cost is not too high, as I keep having huge runtimes.
Am 12.01.2012 14:23, schrieb Matthew Skala:
> [re-sending - I mistakenly sent the first copy from home address that
> isn't subscribed]
> On Thu, 12 Jan 2012, Susanne Niess wrote:
>> As a comment mentioned that local functions have been made static, I suppose
>> there is an alternative although I do not know how because I have never worked
>> with local functions. Is there a nauty version that I can use with
> I don't think static functions are your problem, but static variables.
> I've been able to use nauty in a multithreaded program by changing the
> source code to add the "__thread" keyword to all static variables; this is
> in gcc with pthreads, and I doubt that it's very portable. I use the
> attached Perl script, with a command line like this:
> ./mkts '__thread' nauty.c> tnauty.c
> applied to each of nauty's .c and .h files, to create similarly-named
> files prefixed with "t". This is actually done automatically by my
> project's Makefile in a fairly obvious way. The exact details of the
> include-modifying lines in the script might have to be changed if you're
> including a different set of headers.
> I don't know how useful that will be to anyone but myself - it is part of
> a project that's still quite experimental and some distance away from the
> project as a whole being ready to share - but the fundamental idea is
> simple. Any variables that are static in nauty become thread-local. The
> directive to do this might not be "__thread" if you're using something
> other than gcc and Linux; that's why I made it a command-line argument to
> the script, with eventual portability to other systems being a hope.
> Although nauty's code does not technically become re-entrant with this
> change (I couldn't invoke nauty again in the *same* thread during a nauty
> call) it at least gives me the ability to invoke more than one copy of
> nauty at the same time in *separate* threads, which is enough for my
> Making variables thread-local probably has some performance cost. I
> haven't tried to measure that, but it doesn't seem to have caused a
> noticeable problem for me.
> Static functions are a red herring; those are just the opposite of
> "external" functions, and they don't inherently raise any multithreading
> Nauty-list mailing list
> Nauty-list at cs.anu.edu.au
More information about the Nauty