Menu
▾
▴
flint-devel
|
From: Bill H. <goo...@go...> - 2009-02-11 19:39:14
|
I have just committed changes to the development version of FLINT to make the test_support and memory_manager code thread safe. I've verified that all tests in fmpz_poly-test can now run in parallel without issues and fixed numerous issues with thread safety in that module. All of the functions in fmpz_poly are fully threadsafe, with the exception of: * _fmpz_poly_mul_modular is not threadsafe (it stores static information - Gonzalo and I are working on fixing it). Some of the biggest issues were: * mpn_random2 is not threadsafe and segfaults * the stack based memory manager in FLINT was not threadsafe as it did not set up per thread stacks * use of randstate_t's in test support without initialising per thread was not threadsafe * everything needs cleaning up when joining threads (i.e. the per thread memory managers and random states), otherwise you get a memory leak - there is now a macro in flint.h for doing this cleanup, though OpenMP does not seem to have a mechanism for doing automatic cleanup on joining threads, so this is the user's responsibility I have not checked the thread safety of any other part of FLINT, however I am unaware of anything else that is not threadsafe except the random functions in long_extras and the stack based mpz_t allocator in the mpz_extras module (which no one uses anyway). It is my hope that FLINT 1.2 will be fully threadsafe. Note gcc 4.2.4 or higher is currently needed to compile the development version of FLINT. I'll put some checking in for lower versions in FLINT 1.2 before releasing (and OpenMP stuff just won't be available to people with older versions of gcc). I haven't decided whether to have the tests to run in parallel or not. Currently some of them run much faster in parallel, and some much slower. Bill. |
|
From: Michael A. <mab...@go...> - 2009-02-11 19:47:29
|
On Wed, Feb 11, 2009 at 11:39 AM, Bill Hart <goo...@go...> wrote: Hi Bill, > I have just committed changes to the development version of FLINT to > make the test_support and memory_manager code thread safe. Cool. Can one turn off the use of threads or is this code deeply interwoven with the rest of the code? I am asking because I am keeping an eye out for the native Windows port. > I've verified that all tests in fmpz_poly-test can now run in parallel > without issues and fixed numerous issues with thread safety in that > module. All of the functions in fmpz_poly are fully threadsafe, with > the exception of: > > * _fmpz_poly_mul_modular is not threadsafe (it stores static > information - Gonzalo and I are working on fixing it). > > Some of the biggest issues were: > > * mpn_random2 is not threadsafe and segfaults > * the stack based memory manager in FLINT was not threadsafe as it did > not set up per thread stacks > * use of randstate_t's in test support without initialising per thread > was not threadsafe > * everything needs cleaning up when joining threads (i.e. the per > thread memory managers and random states), otherwise you get a memory > leak - there is now a macro in flint.h for doing this cleanup, though > OpenMP does not seem to have a mechanism for doing automatic cleanup > on joining threads, so this is the user's responsibility > > I have not checked the thread safety of any other part of FLINT, > however I am unaware of anything else that is not threadsafe except > the random functions in long_extras and the stack based mpz_t > allocator in the mpz_extras module (which no one uses anyway). > > It is my hope that FLINT 1.2 will be fully threadsafe. > > Note gcc 4.2.4 or higher is currently needed to compile the > development version of FLINT. I'll put some checking in for lower > versions in FLINT 1.2 before releasing (and OpenMP stuff just won't be > available to people with older versions of gcc). Mhh, mandating gcc 4.2 or higher would be a problem for Sage since currently we only need C99 support, i.e. gcc 3.4.x or higher. If this dependency comes out of the need for OpenMP and it cannot be turned off via some config options this is a major issue. > I haven't decided whether to have the tests to run in parallel or not. > Currently some of them run much faster in parallel, and some much > slower. :) > Bill. Cheers, Michael > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > flint-devel mailing list > fli...@li... > https://lists.sourceforge.net/lists/listinfo/flint-devel > |
|
From: Bill H. <goo...@go...> - 2009-02-11 19:57:16
|
2009/2/11 Michael Abshoff <mab...@go...>: > On Wed, Feb 11, 2009 at 11:39 AM, Bill Hart <goo...@go...> wrote: > > Hi Bill, > >> I have just committed changes to the development version of FLINT to >> make the test_support and memory_manager code thread safe. > > Cool. Can one turn off the use of threads or is this code deeply > interwoven with the rest of the code? I am asking because I am keeping > an eye out for the native Windows port. FLINT has been linking with pthreads since about version 0.0.1., not that it is needed for anything. The only thing which needs to be defined by the compiler is __thread, and even then, I will disable this for non-gcc compatible compilers. This means that FLINT will not be threadsafe when compiled with non-gcc compatible compilers, unless they offer something similar to gcc in the way of thread local variables (most compilers do). I don't know about Windows compilers. I've not checked if they offer thread local variables, and if so, how they do it. > >> I've verified that all tests in fmpz_poly-test can now run in parallel >> without issues and fixed numerous issues with thread safety in that >> module. All of the functions in fmpz_poly are fully threadsafe, with >> the exception of: >> >> * _fmpz_poly_mul_modular is not threadsafe (it stores static >> information - Gonzalo and I are working on fixing it). >> >> Some of the biggest issues were: >> >> * mpn_random2 is not threadsafe and segfaults >> * the stack based memory manager in FLINT was not threadsafe as it did >> not set up per thread stacks >> * use of randstate_t's in test support without initialising per thread >> was not threadsafe >> * everything needs cleaning up when joining threads (i.e. the per >> thread memory managers and random states), otherwise you get a memory >> leak - there is now a macro in flint.h for doing this cleanup, though >> OpenMP does not seem to have a mechanism for doing automatic cleanup >> on joining threads, so this is the user's responsibility >> >> I have not checked the thread safety of any other part of FLINT, >> however I am unaware of anything else that is not threadsafe except >> the random functions in long_extras and the stack based mpz_t >> allocator in the mpz_extras module (which no one uses anyway). >> >> It is my hope that FLINT 1.2 will be fully threadsafe. >> >> Note gcc 4.2.4 or higher is currently needed to compile the >> development version of FLINT. I'll put some checking in for lower >> versions in FLINT 1.2 before releasing (and OpenMP stuff just won't be >> available to people with older versions of gcc). > > Mhh, mandating gcc 4.2 or higher would be a problem for Sage since > currently we only need C99 support, i.e. gcc 3.4.x or higher. If this > dependency comes out of the need for OpenMP and it cannot be turned > off via some config options this is a major issue. This is only the current development version, not the released version. It's only temporary. I will check for the gcc version, and if it is not 2.4 or higher, the user will not be able to use OpenMP with FLINT. Whoopdidoo, they couldn't use OpenMP anyway, because it is broken before gcc 4.2.4. Obviously FLINT will still compile without OpenMP support on earlier gcc's. > >> I haven't decided whether to have the tests to run in parallel or not. >> Currently some of them run much faster in parallel, and some much >> slower. > > :) > >> Bill. > > Cheers, > > Michael > >> ------------------------------------------------------------------------------ >> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) >> software. With Adobe AIR, Ajax developers can use existing skills and code to >> build responsive, highly engaging applications that combine the power of local >> resources and data with the reach of the web. Download the Adobe AIR SDK and >> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com >> _______________________________________________ >> flint-devel mailing list >> fli...@li... >> https://lists.sourceforge.net/lists/listinfo/flint-devel >> > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > flint-devel mailing list > fli...@li... > https://lists.sourceforge.net/lists/listinfo/flint-devel > |
|
From: Michael A. <mab...@go...> - 2009-02-11 20:30:44
|
On Wed, Feb 11, 2009 at 11:57 AM, Bill Hart <goo...@go...> wrote: > 2009/2/11 Michael Abshoff <mab...@go...>: >> On Wed, Feb 11, 2009 at 11:39 AM, Bill Hart <goo...@go...> wrote: >> >> Hi Bill, >> >>> I have just committed changes to the development version of FLINT to >>> make the test_support and memory_manager code thread safe. >> >> Cool. Can one turn off the use of threads or is this code deeply >> interwoven with the rest of the code? I am asking because I am keeping >> an eye out for the native Windows port. > > FLINT has been linking with pthreads since about version 0.0.1., not > that it is needed for anything. Ok. No harm done here. phtread is available in 32 and 64 bit flavors for Windows, but I have doubts about the maturity. > The only thing which needs to be defined by the compiler is __thread, > and even then, I will disable this for non-gcc compatible compilers. > This means that FLINT will not be threadsafe when compiled with > non-gcc compatible compilers, unless they offer something similar to > gcc in the way of thread local variables (most compilers do) Ok. A FLINT without threads with MSVC is better than no FLINT at all. Similar things do apply do David's parallel Bernoulli code in Sage which has compile issues on Cygwin at the moment, but for now I will likely just turn off threading until I fix the issue :) > I don't > know about Windows compilers. I've not checked if they offer thread > local variables, and if so, how they do it. Yes, I think TLS is doable with MSVC, but I won't claim to know it until I try. >>> I've verified that all tests in fmpz_poly-test can now run in parallel >>> without issues and fixed numerous issues with thread safety in that >>> module. All of the functions in fmpz_poly are fully threadsafe, with >>> the exception of: >>> >>> * _fmpz_poly_mul_modular is not threadsafe (it stores static >>> information - Gonzalo and I are working on fixing it). >>> >>> Some of the biggest issues were: >>> >>> * mpn_random2 is not threadsafe and segfaults >>> * the stack based memory manager in FLINT was not threadsafe as it did >>> not set up per thread stacks >>> * use of randstate_t's in test support without initialising per thread >>> was not threadsafe >>> * everything needs cleaning up when joining threads (i.e. the per >>> thread memory managers and random states), otherwise you get a memory >>> leak - there is now a macro in flint.h for doing this cleanup, though >>> OpenMP does not seem to have a mechanism for doing automatic cleanup >>> on joining threads, so this is the user's responsibility >>> >>> I have not checked the thread safety of any other part of FLINT, >>> however I am unaware of anything else that is not threadsafe except >>> the random functions in long_extras and the stack based mpz_t >>> allocator in the mpz_extras module (which no one uses anyway). >>> >>> It is my hope that FLINT 1.2 will be fully threadsafe. >>> >>> Note gcc 4.2.4 or higher is currently needed to compile the >>> development version of FLINT. I'll put some checking in for lower >>> versions in FLINT 1.2 before releasing (and OpenMP stuff just won't be >>> available to people with older versions of gcc). >> >> Mhh, mandating gcc 4.2 or higher would be a problem for Sage since >> currently we only need C99 support, i.e. gcc 3.4.x or higher. If this >> dependency comes out of the need for OpenMP and it cannot be turned >> off via some config options this is a major issue. > > This is only the current development version, not the released > version. It's only temporary. I will check for the gcc version, and if > it is not 2.4 or higher, the user will not be able to use OpenMP with > FLINT. 4.2, but yes. > Whoopdidoo, they couldn't use OpenMP anyway, because it is > broken before gcc 4.2.4. And some people do claim that OpenMP with other compilers like the PathScale or Intel compiler is still superior to the version in gcc 4.3, too :) > Obviously FLINT will still compile without > OpenMP support on earlier gcc's. Excellent, that is all I wanted to hear. Cheers, Michael |
|
From: Bill H. <goo...@go...> - 2009-02-12 19:19:17
|
I've now made the multi modular reduction functions in fmpz thread safe. This make _fmpz_poly_mul_modular and fmpz_poly_mul_modular threadsafe. That means all of fmpz_poly is now threadsafe. Bill. 2009/2/11 Michael Abshoff <mab...@go...>: > On Wed, Feb 11, 2009 at 11:57 AM, Bill Hart <goo...@go...> wrote: >> 2009/2/11 Michael Abshoff <mab...@go...>: >>> On Wed, Feb 11, 2009 at 11:39 AM, Bill Hart <goo...@go...> wrote: >>> >>> Hi Bill, >>> >>>> I have just committed changes to the development version of FLINT to >>>> make the test_support and memory_manager code thread safe. >>> >>> Cool. Can one turn off the use of threads or is this code deeply >>> interwoven with the rest of the code? I am asking because I am keeping >>> an eye out for the native Windows port. >> >> FLINT has been linking with pthreads since about version 0.0.1., not >> that it is needed for anything. > > Ok. No harm done here. phtread is available in 32 and 64 bit flavors > for Windows, but I have doubts about the maturity. > >> The only thing which needs to be defined by the compiler is __thread, >> and even then, I will disable this for non-gcc compatible compilers. >> This means that FLINT will not be threadsafe when compiled with >> non-gcc compatible compilers, unless they offer something similar to >> gcc in the way of thread local variables (most compilers do) > > Ok. A FLINT without threads with MSVC is better than no FLINT at all. > Similar things do apply do David's parallel Bernoulli code in Sage > which has compile issues on Cygwin at the moment, but for now I will > likely just turn off threading until I fix the issue :) > >> I don't >> know about Windows compilers. I've not checked if they offer thread >> local variables, and if so, how they do it. > > Yes, I think TLS is doable with MSVC, but I won't claim to know it until I try. > >>>> I've verified that all tests in fmpz_poly-test can now run in parallel >>>> without issues and fixed numerous issues with thread safety in that >>>> module. All of the functions in fmpz_poly are fully threadsafe, with >>>> the exception of: >>>> >>>> * _fmpz_poly_mul_modular is not threadsafe (it stores static >>>> information - Gonzalo and I are working on fixing it). >>>> >>>> Some of the biggest issues were: >>>> >>>> * mpn_random2 is not threadsafe and segfaults >>>> * the stack based memory manager in FLINT was not threadsafe as it did >>>> not set up per thread stacks >>>> * use of randstate_t's in test support without initialising per thread >>>> was not threadsafe >>>> * everything needs cleaning up when joining threads (i.e. the per >>>> thread memory managers and random states), otherwise you get a memory >>>> leak - there is now a macro in flint.h for doing this cleanup, though >>>> OpenMP does not seem to have a mechanism for doing automatic cleanup >>>> on joining threads, so this is the user's responsibility >>>> >>>> I have not checked the thread safety of any other part of FLINT, >>>> however I am unaware of anything else that is not threadsafe except >>>> the random functions in long_extras and the stack based mpz_t >>>> allocator in the mpz_extras module (which no one uses anyway). >>>> >>>> It is my hope that FLINT 1.2 will be fully threadsafe. >>>> >>>> Note gcc 4.2.4 or higher is currently needed to compile the >>>> development version of FLINT. I'll put some checking in for lower >>>> versions in FLINT 1.2 before releasing (and OpenMP stuff just won't be >>>> available to people with older versions of gcc). >>> >>> Mhh, mandating gcc 4.2 or higher would be a problem for Sage since >>> currently we only need C99 support, i.e. gcc 3.4.x or higher. If this >>> dependency comes out of the need for OpenMP and it cannot be turned >>> off via some config options this is a major issue. >> >> This is only the current development version, not the released >> version. It's only temporary. I will check for the gcc version, and if >> it is not 2.4 or higher, the user will not be able to use OpenMP with >> FLINT. > > 4.2, but yes. > >> Whoopdidoo, they couldn't use OpenMP anyway, because it is >> broken before gcc 4.2.4. > > And some people do claim that OpenMP with other compilers like the > PathScale or Intel compiler is still superior to the version in gcc > 4.3, too :) > >> Obviously FLINT will still compile without >> OpenMP support on earlier gcc's. > > Excellent, that is all I wanted to hear. > > Cheers, > > Michael > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > flint-devel mailing list > fli...@li... > https://lists.sourceforge.net/lists/listinfo/flint-devel > |
Thanks for helping keep SourceForge clean.
X