Re: [Mingw-w64-public] gcc 5.2.1 libgomp testsuite failures with latest runtime and winpthread
7 aug 2015 kl. 14.50 skrev Rainer Emrich rai...@emrich-ebersheim.de: This fixes the issue, libgom.sum attached. Can we have this in head and in 4.x ? That is probably the expedient solution even if we eventually get libgomp fixed. (The patch adds an extra cycle or two on some critical paths but I suppose we can live with that.) Fixing libgomp is probably cleaner: either make sure the constructors are run in the right order or initialize the acc_device_lock mutex statically. Are you willing to work on this? I can't, I don't have the skills. It looks quite straightforward actually, but probably better done by the libgomp maintainers upstreams. A GCC bug has been filed: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67141 -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] gcc 5.2.1 libgomp testsuite failures with latest runtime and winpthread
6 aug 2015 kl. 12.46 skrev Rainer Emrich sf.rai...@emrich-ebersheim.de:
Using the x86_64 runtime and winpthread from 4th of August I get a lot of
libgomp testsuite failures. Nearly all execution tests fail!!! That's a
regression against older runtime/winpthread versions.
I assume that's caused by the latest winpthread changes.
Sort of; it looks like a bug in libgomp that was tolerated by the old mutex
implementation.
The acc_device_lock mutex is initialized in initialize_env and used in
goacc_host_init, both which are declared __attribute__ ((constructor)). Such
constructors are not called in a very predictable order, and apparently we
weren't lucky this time.
The easy way is to make winpthread's mutex implementation more forgiving
(treating 0-filled memory as if it were PTHREAD_MUTEX_INITIALIZER). Patch:
diff --git a/mingw-w64-libraries/winpthreads/src/mutex.c
b/mingw-w64-libraries/wi
index fec341a..6e1b392 100644
--- a/mingw-w64-libraries/winpthreads/src/mutex.c
+++ b/mingw-w64-libraries/winpthreads/src/mutex.c
@@ -56,7 +56,10 @@ typedef struct {
static bool
is_static_initializer(pthread_mutex_t m)
{
- return (uintptr_t)m = (uintptr_t)-3;
+ /* Treat 0 as a static initializer as well (for normal mutexes),
+ to tolerate sloppy code in libgomp. (We should rather fix that code!) */
+ intptr_t v = (intptr_t)m;
+ return v = -3 v = 0;
}
/* Create and return the implementation part of a mutex from a static
Fixing libgomp is probably cleaner: either make sure the constructors are run
in the right order or initialize the acc_device_lock mutex statically.
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] winpthreads
For debugging issue can be used OpmeMP test https://github.com/niXman/mingw-builds/blob/master/tests/omp_test.c Build it with «gcc omp_test.c -fopenmp -o omp_test.exe» and run. No crash when I run that code. Is this the same for everybody else? Perhaps you could find a different test case. That is, if the error is real and not due to a configuration mistake. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Winpthreads slow mutexes - still applies?
19 jun 2015 kl. 23.12 skrev Alexandre Pereira Nunes alexandre.nu...@gmail.com: I came across this: https://sourceforge.net/p/mingw-w64/bugs/344/ Does anyone knows if that's still the case? Yes. There is a patch, but it has not been cleared for release yet. It may take a few weeks more, given that people are on holiday. I shall try to accelerate the process. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] printf speedup [PATCH]
patch is ok. I am still a bit curious to learn about that high delay caused by getenv (). It was a while since I dissected it, but I believe getenv takes a lock. This hurts multithreaded programs in particular. Even without a lock, getenv still needs to do a linear string search through the entire environment (because it typically fails). -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] printf speedup [PATCH]
1 apr 2015 kl. 05.35 skrev Dongsheng Song dongsheng.s...@gmail.com: In my testing, getenv() is very fast. *) unset PRINTF_EXPONENT_DIGITS preheat 1 times, then perform 100 times (use 4.6 seconds) getenv cost: 4.6 us *) set PRINTF_EXPONENT_DIGITS=3 preheat 1 times, then perform 100 times (use 3.41991 seconds) getenv: 3.41991 us 4 µs is a lot on a modern CPU, and an unacceptable overhead for a basic library function such as sprintf. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] printf speedup [PATCH]
The functions in the __mingw_printf family are very slow because of the
getenv(”PRINTF_EXPONENT_DIGITS”) call that is made every time, even when that
information isn’t actually needed.
Please consider this patch. It only calls getenv once, caching the result (as
is traditionally done in libraries that use environment variables this way). It
also only computes the minimum exponent digits when actually needed, at most
once per format call.
With this patch, __mingw_sprintf(buf, ”x”) goes from being several orders of
magnitude slower than the MSVCRT sprintf, to about 66% faster. You don’t see
this kind of improvement every day.
--- mingw-w64-crt/stdio/mingw_pformat.c.orig2015-03-31 20:27:41.000465100
+0200
+++ mingw-w64-crt/stdio/mingw_pformat.c 2015-03-31 21:42:05.990919500 +0200
@@ -171,12 +171,17 @@
static
int __pformat_exponent_digits( void )
{
- char *exponent_digits = getenv( PRINTF_EXPONENT_DIGITS );
- return ((exponent_digits != NULL) ((unsigned)(*exponent_digits - '0')
3))
-|| (_get_output_format() _TWO_DIGIT_EXPONENT)
-? 2
-: 3
-;
+ /* Calling getenv is expensive; only do it once and cache the result. */
+ static int two_exp_digits_env = -1;
+ if (two_exp_digits_env == -1) {
+const char *exponent_digits_env = getenv( PRINTF_EXPONENT_DIGITS );
+two_exp_digits_env = exponent_digits_env != NULL
+ (unsigned)(*exponent_digits_env - '0') 3;
+ }
+ return (two_exp_digits_env || (_get_output_format() _TWO_DIGIT_EXPONENT))
+ ? 2
+ : 3
+ ;
}
#else
/*
@@ -1222,6 +1227,8 @@
/* Ensure that this is at least as many as the standard requirement.
*/
+ if (stream-expmin == -1)
+stream-expmin = PFORMAT_MINEXP;
if( exp_width stream-expmin )
exp_width = stream-expmin;
@@ -1817,7 +1824,8 @@
(wchar_t)(0), /* leave it unspecified */
0, /* zero output char count */
max, /* establish output limit */
-PFORMAT_MINEXP /* exponent chars preferred */
+-1 /* exponent chars preferred;
+ -1 means to be determined.
*/
};
format_scan: while( (c = *fmt++) != 0 )
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
