2008/7/17 Peter W. Draper <[log in to unmask]>:
> On Thu, 17 Jul 2008, David Berry wrote:
>
>> 2008/7/17 Peter W. Draper <[log in to unmask]>:
>>>
>>> On Wed, 16 Jul 2008, Tim Jenness wrote:
>>>
>>>> Peter,
>>>>
>>>> Is it worth moving thread-safe ems into trunk so that we can start
>>>> using
>>>> it on a daily basis? I have no idea if David is testing it in his
>>>> threaded
>>>> smurf but I think we should be giving the thread-safe ems a bashing in
>>>> single thread mode for a while.
>>>>
>>>> I'm hoping that AST thread-safe will be default for the next release in
>>>> the Autumn.
>>>
>>> Sounds like we should move it over as soon as possible. I've been using
>>> it
>>> (in thread-enabled mode, but naturally without any actual threads) and
>>> haven't had any problems, David has reported nothing from his SMURF
>>> efforts
>>> (but remains highly suspicious of everything I see),
>>
>> I've been in touch with Tim about this - sorry for leaving you out.
>> Basically, on AMD systems the multi-threaded smurf seems to work,
>> giving the same output cubes as before, but with only marginal
>> decreases in run-time. In fact, the multi-threaded makemap application
>> takes slightly *more* time to run than the un-threaded version. There
>> seems to be a lot of contention going on somewhere. I don't know yet
>> whether it is related to the CPU cache or to application data
>> structures.
>>
>> Things are worse on Intel systems, in that the multi-threaded apps
>> often fail to run at all, crashing at random places. Using Intel
>> compilers rather than gnu seems to fix this crashing problem. But of
>> course we cannot rely on Intel compilers. At the moment, I'm
>> struglling with the Intel thread checker tool, to see if it can cast
>> any light on where thingsd are going wrong.
>
> Sounds grim. I saw the numbers posted by Brad a while back and thought it
> looked not quite as fast as we'd hoped, but didn't realise things where this
> bad.
>
> One thought occurred to me about GCC crashing, it does have a flag
> -pthread(s) that is used on some platforms for compiling, so I've had a
> quick look at that area again.
Yes. I was in some confusion about whether we should be using -pthread
or -lpthread. I found something somewhere that said that -pthread
implied -lpthread, and also caused app to be linked with the
thread-safe versions of the run-time-library. So I decided to go with
-pthread, and leave out -lpthread.
> Anyway I now think we should be defining
> -D_REENTRANT when compiling. This supposedly makes any references to errno
> protected and I can see some naked references to that in AST (object.c,
> axis.c, channel.c, mathmap.c). Worth a try.
Thanks for the tip. Do you have any references for -D_REENTRANT. A
quick google produces very little.
In some breaking news, the Intel thread checker has thrown up a usage
of Fortran SLALIB (from smurf, not AST), together with some static
variables in smurf that I had over-looked. So I've got a few leads to
go on now.
David
|