Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
|
From: Earnie Boyd <earnie_boyd@ya...> - 2003-05-07 03:24:09
Attachments:
Changes.mingw
|
This release among other things adds a _CRTIMP modifier to the import declarations. It's default definition is set to nothing. It will be set to __declspec(dllimport) if you -D__USE_CRTIMP which will provide a slight speed improvement to your process but will cause multiply defined symbols if you provide a local definition of a shared function, for example malloc. The relevant portion of the ChangeLog is attached. Earnie. |
|
From: Luke Dunstan <coder_infidel@ho...> - 2003-05-07 10:19:05
|
The release notes page: https://sourceforge.net/project/shownotes.php?release_id=84152 contains a link to mingw-runtime-2.3.tar.gz, so be careful not to get that instead of 3.0. Luke ----- Original Message ----- From: "Earnie Boyd" <earnie_boyd@...> To: "MinGW Users" <mingw-users@...> Sent: Wednesday, May 07, 2003 11:23 AM Subject: [Mingw-users] Released: mingw-runtime-3.0-1.tar.gz > This release among other things adds a _CRTIMP modifier to the import > declarations. It's default definition is set to nothing. It will be > set to __declspec(dllimport) if you -D__USE_CRTIMP which will provide a > slight speed improvement to your process but will cause multiply defined > symbols if you provide a local definition of a shared function, for > example malloc. The relevant portion of the ChangeLog is attached. > > Earnie. > ---------------------------------------------------------------------------- ---- > 2003-05-06 Earnie Boyd <earnie@...> > > * configure.in (W32API_INCLUDE): Need the -I switch in the value. > * mingwex/configure.in (W32API_INCLUDE): Ditto. > * profile/configure.in (W32API_INCLUDE): Ditto. > > 2003-05-06 Earnie Boyd <earnie@...> > > * configure.in (CFLAGS): Remove -D__USE_CRTIMP=1 due to possibilites > of multiply defined symbols if the symbols is defined locally. E.G.: > A local definition of malloc causes this problem. > * configure: Regenerate. > * profile/Makefile.in (W32API_INCLUDE): New variable. > (ALL_CFLAGS): Use W32API_INCLUDE value. > (ALL_CXXFLAGS): Ditto. > (gcrt0.o gcrt1.o gcrt2.o): Use ALL_CFLAGS instead of CFLAGS. > Thanks to Jeff Bonggren <jbon@...>. > * profile/configure.in (W32API_INCLUDE): Set default value. > * profile/configure: Regenerate. > * mingwex/Makefile.in (W32API_INCLUDE): New variable. > (ALL_CFLAGS): Use W32API-INCLUDE value. > (ALL_CXXFLAGS): Ditto. > * mingwex/configure.in (W32API_INCLUDE): Set default value. > * mingwex/configure: Regenerate. > > 2003-05-05 Earnie Boyd <earnie@...> > > * Makefile.in (W32API_INCLUDE): New variable. > (ALL_CFLAGS): Use W32API_INCLUDE value. > (ALL_CXXFLAGS): Ditto. > * configure.in (CFLAGS): Add -D__USE_CRTIMP=1 to default values. > (W32API_INCLUDE): Set default value. > * configure: Regenerate. > > 2003-04-11 Earnie Boyd <earnie@...> > > * configure.in (LIBM_A): Define for cygwin target. > * configure (LIBM_A): Ditto. > > 2003-04-07 Danny Smith <dannysmith@...> > > * include/time.h (strftime): Remove duplicate declaration. > > 2003-04-01 Danny Smith <dannysmith@...> > > * include/_mingw.h (_CRTIMP): Make conditional on __USE_CRTIMP. > > 2003-03-16 Danny Smith <dannysmith@...> > > * mingwex/dirent.c (_topendir): Eliminate signed/unsigned warning. > * mingwex/strtoimax.c (strtoimax): Likewise. > * mingwex/wcstoimax.c (wcstoimax): Likewise. > * mingwex/wtoll.c (wtoll): Remove unnecessary ';' > * mingwex/fesentenv.c: Include float.h. > * mingwex/math/powl.c: Eliminate type punning/strict aliasing > warning. > * mingwex/math/tanhl.c: Eliminate signed/unsigned warning in > constants. > * mingwex/math/tgammal.c: Likewise. > > 2003-03-16 Danny Smith <dannysmith@...> > > * include/utime.h: New file, forwarding to sys/utime.h. > > 2003-03-16 Danny Smith <dannysmith@...> > > * include/sys/param.h (MAXPATHLEN): Define. > > 2003-03-16 Danny Smith <dannysmith@...> > > * include/tchar.h: Ansi-fy a comment. > > 2003-03-16 Danny Smith <dannysmith@...> > > * profile/profile.h (mcount): Use __builtin_return_address > rather than inline __asm statements. > * profile/Makefile.in: Remove special rule for mcount.o > Specify dependencies for mcount.o profil.o gmon.o. > > 2003-03-10 Danny Smith <dannysmith@...> > > * include/stdlib.h (qsort): Remove const from first parm. > Thanks to: Tien-Ren Chen <trchen@...> > > 2003-03-03 Christopher Faylor <cgf@...> > > * mingwex/getopt.c: Refresh from NetBSD sources. > > 2003-03-03 Danny Smith <dannysmith@...> > > * mingwex/getopt.c: New file, copied from cygwin srcs. > * include/getopt.h: New file, copied from cygwin srcs. > * include/unistd.h: Include getopt.h. > * mingwex/Makefile.in (DISTFILES): Add getopt.c. > (POSIX_OBJS): Add getopt.o. > > 2003-03-02 Danny Smith <dannysmith@...> > > * include/stdio.h (vscanf): Add prototype. > (vfscanf): Ditto. > (vsscanf): Ditto. > (vwscanf): Ditto. > (vfwscanf): Ditto. > (vswscanf): Ditto. > * include/wchar.h (vwscanf): Add prototype. > (vfwscanf): Ditto. > (vswscanf): Ditto. > * mingwex/snprintf.c: Move to mingwex/stdio. > * mingwex/vsnprintf.c: Ditto. > * mingwex/snwprintf.c: Ditto. > * mingwex/vsnwprintf.c: Ditto. > * mingwex/Makefile.in (VPATH): Add $(srcdir)/stdio > (STDIO_DISTFILES): Add. > (DISTFILES): Adjust. > (STDIO_STUB_OBJS): Rename to STDIO_OBJS and add v*scanf objects. > (LIB_OBJS): Adjust. > (dist): Adjust. > > 2003-03-02 Aaron W LaFramboise <AWLaFramboise@...> > > * mingwex/stdio: New directory > * mingwex/stdio/vfscanf.c: New file. > * mingwex/stdio/vfwscanf.c: New file. > * mingwex/stdio/vscanf.c: New file. > * mingwex/stdio/vsscanf.c: New file. > * mingwex/stdio/vswscanf.c: New file. > * mingwex/stdio/vwscanf.c: New file. > > 2003-02-25 Earnie Boyd <earnie@...> > > * Makefile.in (libmsvcrt20.a): Remove target and dependencies. > (libmsvcrt40.a): Ditto. > > 2003-02-21 Earnie Boyd <earnie@...> > > Thanks to David Frasier <davidf@...> who inspired portions of > this patch. > * Makefile.in (libmsvcrtd.a): Add target library. > (libmoldnamed.a): Ditto. > (msvcrt.def, msvcrtd.def, msvcrt20.def, msvcrt40.def): Use msvcrt.def.in > template to create. > ($(srcdir)): Remove explicit reference for depencies of object targets. > * moldname.def, moldname-msvcrt.def, moldname-crtdll.def, msvcrt.def, > msvcrt20.def, msvcrt40.def: Remove. > * msvcrt.def.in: New file (Copy of previous msvcrt.def). > > 2003-02-20 Corinna Vinschen <corinna@...> > > * Makefile.in: Make sure libmingwex.a from current build tree is used. > > 2003-02-14 Christopher Faylor <cgf@...> > > * profile/Makefile.in (mcount.o): Use ALL_CFLAGS for compilation to > ensure -mno-cygwin where appropriate. Filter out -O2. > > 2003-02-13 Danny Smith <dannysmith@...> > > * profile/Makefile.in (mcount.o): Use -O1 optimization > switch to compile. > > 2003-02-10 Danny Smith <dannysmith@...> > > * include/math.h: Remove _CRTIMP from pow() prototype, > unless __NO_ISOCEXT. > > 2003-02-10 Danny Smith <dannysmith@...> > > * mingwex/math/cephes_emath.h: Don't redefine INFINITY. > > 2003-02-10 Danny Smith <dannysmith@...> > > * include/_mingw.h (_CRTIMP): Define for __GNUC__ if > __declspec(dllimport) supported. > (__cdecl): Define if not already defined. > (__stdcall): Likewise. > * include/dirent.h: Qualify fuctions with __cdecl. > * include/fenv.h: Likewise. > * include/inttypes.h: Likewise. > * include/assert.h: Qualify fuctions with __cdecl. Qualify > CRT dll imports with _CRTIMP. > * include/conio.h: Likewise. > * include/ctype.h: Likewise. > * include/direct.h: Likewise. > * include/dos.h: Likewise. > * include/errno.h: Likewise. > * include/float.h: Likewise. > * include/io.h: Likewise. > * include/locale.h: Likewise. > * include/malloc.h: Likewise. > * include/math.h: Likewise. > * include/mbctype.h: Likewise. > * include/mbstring.h: Likewise. > * include/process.h: Likewise. > * include/setjmp.h: Likewise. > * include/signal.h: Likewise. > * include/stdio.h: Likewise. > * include/stdlib.h: Likewise. > * include/string.h: Likewise. > * include/time.h: Likewise. > * include/wchar.h: Likewise. > * include/wctype.h: Likewise. > * include/sys/stat.h: Likewise. > * include/sys/timeb.h: Likewise. > * include/sys/utime.h: Likewise. > > * include/ctype.h: Guard ctype inlines with __NO_INLINE__. > * include/wctype.h: Guard wctype inlines with __NO_INLINE__. > > * include/stdio.h (__VALIST): Guard against prior definition. > > |
|
From: Norman Vine <nhv@ca...> - 2003-05-12 23:33:05
Attachments:
qsort.tgz
|
Hi all Is it a known issue that qsort with MingW is often an order of magnitude slower then the Cygwin qsort ?? If so should we add a qsort ? Attached is my port of the one from Newlib which seems to work fine and I believe has an appropriate license Cheers Norman |
|
From: Oscar Fuentes <ofv@wa...> - 2003-05-13 00:16:14
|
"Norman Vine" <nhv@...> writes: > Hi all > > Is it a known issue that qsort with MingW is > often an order of magnitude slower then the > Cygwin qsort ?? IMO, this claim is too vague. Could you provide a more precise description, please? > If so should we add a qsort ? > > Attached is my port of the one from Newlib > which seems to work fine and I believe has > an appropriate license Have you modified that code at all? In what sense is it "a port"? From where can we get guarantees about its correction, descriptions of its behavior, etc? IMHO, it's not a good idea to replace the MSVCRT implementation, which is a old known, extensively used qsort, with something else without a *very* good reason. -- Oscar |
|
From: <danny_r_smith_2001@ya...> - 2003-05-13 02:12:01
|
--- Oscar Fuentes <ofv@...> wrote: > "Norman Vine" <nhv@...> writes: > > > Hi all > > > > Is it a known issue that qsort with MingW is > > often an order of magnitude slower then the > > Cygwin qsort ?? > > IMO, this claim is too vague. Could you provide a more precise > description, please? > > > If so should we add a qsort ? > > > > Attached is my port of the one from Newlib > > which seems to work fine and I believe has > > an appropriate license > > Have you modified that code at all? In what sense is it "a port"? From > where can we get guarantees about its correction, descriptions of its > behavior, etc? > > IMHO, it's not a good idea to replace the MSVCRT implementation, which > is a old known, extensively used qsort, with something else without a > *very* good reason. > I agree with Oscar. If you can show me some benchmark results with a range of sorts I might be interested. "Often an order of magnitude slower"is not good enough. I'd quess that MS qsort would "often" be faster with some problems or some machines. Danny > -- > Oscar > > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > http://www.enterpriselinuxforum.com > > _______________________________________________ > MinGW-users mailing list > MinGW-users@... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile. |
|
From: Norman Vine <nhv@ca...> - 2003-05-13 04:37:06
|
Danny Smith writes:
>
> --- Oscar Fuentes <ofv@...> wrote: > "Norman Vine" <nhv@...>
> writes:
> >
> > > Hi all
> > >
> > > Is it a known issue that qsort with MingW is
> > > often an order of magnitude slower then the
> > > Cygwin qsort ??
> >
> > IMO, this claim is too vague. Could you provide a more precise
> > description, please?
Please note this is phrased as a question and not a claim :-)
>
> > > If so should we add a qsort ?
> > >
> > > Attached is my port of the one from Newlib
> > > which seems to work fine and I believe has
> > > an appropriate license
> >
> > Have you modified that code at all? In what sense is it "a port"? From
> > where can we get guarantees about its correction, descriptions of its
> > behavior, etc?
The only change I made to the newlib code was to include the pertinent
definitions that come from the <includes>
e.g.
#ifdef __STDC__
#define _HAVE_STDC
#endif
#ifdef __STDC__
#define _PTR void *
#define _AND ,
#define _NOARGS void
#define _CONST const
#define _VOLATILE volatile
#define _SIGNED signed
#define _DOTS , ...
#define _VOID void
#if defined(__MINGW32__)
#define _DEFUN(name, arglist, args) name(args)
#define _PARAMS(paramlist) paramlist
#endif
#endif
FWIW this is actually more then what is required but I was lazy :-)
> >
> > IMHO, it's not a good idea to replace the MSVCRT implementation, which
> > is a old known, extensively used qsort, with something else without a
> > *very* good reason.
In general I agree but the code I posted is the Berkley qsort which AFAIK is
fairly standard in the non MS world :-)
> >
>
> I agree with Oscar. If you can show me some benchmark results
> with a range of
> sorts I might be interested. "Often an order of magnitude
> slower"is not good
> enough. I'd quess that MS qsort would "often" be faster with some
> problems or some machines.
I wiill try to come up with a 'simple' test case but until then might
I propose that others try using the code on there own data to see
The compare function that brought this to my attention is
int bbcmp(const void *i1,const void *i2)
{
return(vt[0][*(int *)i1]-vt[0][*(int *)i2]);
}
where
#define MAXPTS 50000 /* set this to whatever you wnat */
#define MAXTRI (2*MAXPTS)
int vt[3][MAXTRI];
Again my post was a 'question' not an 'assertion' and I was *very*
surprised by this
Cheers and thanks to all who make MingW what it is !
Norman
|
|
From: Oscar Fuentes <ofv@wa...> - 2003-05-13 05:35:55
|
"Norman Vine" <nhv@...> writes: >> > > Is it a known issue that qsort with MingW is >> > > often an order of magnitude slower then the >> > > Cygwin qsort ?? >> > >> > IMO, this claim is too vague. Could you provide a more precise >> > description, please? > > Please note this is phrased as a question and not a claim :-) Well, the answer is "no", it is not a known issue that qsort with MinGW is often an order of magnitude slower than the Cygwin qsort. At least for me. > The only change I made to the newlib code was to include the pertinent > definitions that come from the <includes> > e.g. [snip] > FWIW this is actually more then what is required but I was lazy :-) It would be a good thing to translate the code to ISO C and eliminate the use of the "register" keyword, among other cosmetic changes. >> > IMHO, it's not a good idea to replace the MSVCRT implementation, which >> > is a old known, extensively used qsort, with something else without a >> > *very* good reason. > > In general I agree but the code I posted is the Berkley qsort which AFAIK is > fairly standard in the non MS world :-) If it is the same implementation used on the *BSD OSes, I'm ok as far as reliability is concerned. >> I agree with Oscar. If you can show me some benchmark results with >> a range of sorts I might be interested. "Often an order of >> magnitude slower"is not good enough. I'd quess that MS qsort would >> "often" be faster with some problems or some machines. > > I wiill try to come up with a 'simple' test case but until then might > I propose that others try using the code on there own data to see This is not simple. As Danny hints, the actual performance depends on several factors, like the pre-existent order on the array, element size, alignment, etc. Also, maybe GCC produces better code than MSVC for some configurations, and vice-versa. I think MSVCRT uses the same algotithm as yours, but with different micro-optimizations. BTW, you didn't put your test case on the same source file where the algorithm was, did you? [snip] > Again my post was a 'question' not an 'assertion' and I was *very* > surprised by this So was I. A tenfold difference is too big for competent implementations of the same algorithm. My guess is that you hit an extreme case. I'm looking forward to your test case. Regards, -- Oscar |
|
From: Greg Chicares <chicares@mi...> - 2003-05-13 05:39:21
|
Norman Vine wrote: > > > --- Oscar Fuentes <ofv@...> wrote: > "Norman Vine" <nhv@...> > > writes: > > > > > > IMHO, it's not a good idea to replace the MSVCRT implementation, which > > > is a old known, extensively used qsort, with something else without a > > > *very* good reason. > > In general I agree but the code I posted is the Berkley qsort which AFAIK is > fairly standard in the non MS world :-) Its license includes what rms calls the "obnoxious BSD advertising clause" http://www.gnu.org/philosophy/bsd.html though perhaps there's a later version that removes that clause. > Danny Smith writes: > > > > I agree with Oscar. If you can show me some benchmark results > > with a range of > > sorts I might be interested. "Often an order of magnitude > > slower"is not good > > enough. I'd quess that MS qsort would "often" be faster with some > > problems or some machines. > > I wiill try to come up with a 'simple' test case but until then might > I propose that others try using the code on there own data to see > > The compare function that brought this to my attention is [...] Perhaps the problem is the data instead of the comparison function. Quicksort is O(N log N) 'usually', but O(N*N) in the worst case. Was your data already sorted? Maybe BSD took better precautions than MS to deal with that case. |
|
From: Andy Ross <andy@pl...> - 2003-05-13 15:08:48
|
Getting a little OT, obviously. But the subject is interesting and this is
a frustratingly common misconception.
Greg Chicares wrote:
> Perhaps the problem is the data instead of the comparison
> function. Quicksort is O(N log N) 'usually', but O(N*N) in the worst
> case. Was your data already sorted? Maybe BSD took better precautions
> than MS to deal with that case.
If the MS qsort is hitting a pessimal case on pre-sorted data then it
is broken; end of story. Real world implementations simply don't do
this, they randomize the pivot choice. The "quicksort is slow on
sorted data" meme is something taught in college courses as a way of
explaining algorithmic complexity theory to new students. It is most
emphatically not a real-world limitation of the algorithm.
By way of anecdote, another common bug with quicksort implementations
is a failure to properly split (into equal halves, of course) large
blocks of repeated values. If you write a < instead of a <= (or
whatnot), you can end up with a correct algorithm with N² behavior on
homogenous arrays.
Andy
--
Andrew J. Ross Beyond the Ordinary Plausibility Productions
Sole Proprietor Beneath the Infinite Hillsboro, OR
Experience... the Plausible?
|
|
From: Norman Vine <nhv@ca...> - 2003-05-13 15:42:38
|
Andy Ross writes: > > Getting a little OT, obviously. But the subject is interesting > and this is > a frustratingly common misconception. > > Greg Chicares wrote: > > Perhaps the problem is the data instead of the comparison > > function. Quicksort is O(N log N) 'usually', but O(N*N) in the worst > > case. Was your data already sorted? Maybe BSD took better precautions > > than MS to deal with that case. > > If the MS qsort is hitting a pessimal case on pre-sorted data then it > is broken; end of story. The data invoved in this case is not 'presorted' but it does contain *many* duplicate values which one wouldn't think would be an issue but .... This is worth further study and the MS source is available in the MS CRT but since the Berkley code runs for me in expected time .... Cheers Norman |
|
From: Greg Chicares <chicares@mi...> - 2003-05-13 21:05:39
|
Andy Ross wrote:
>
> Getting a little OT, obviously. But the subject is interesting and this is
> a frustratingly common misconception.
>
> Greg Chicares wrote:
> > Perhaps the problem is the data instead of the comparison
> > function. Quicksort is O(N log N) 'usually', but O(N*N) in the worst
> > case. Was your data already sorted? Maybe BSD took better precautions
> > than MS to deal with that case.
>
> If the MS qsort is hitting a pessimal case on pre-sorted data then it
> is broken; end of story. Real world implementations simply don't do
> this, they randomize the pivot choice. The "quicksort is slow on
> sorted data" meme is something taught in college courses as a way of
> explaining algorithmic complexity theory to new students. It is most
> emphatically not a real-world limitation of the algorithm.
Let's see...
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int compare(void const* a, void const* b)
{
return *(int*)a - *(int*)b;
}
#define N 100000
int main(int argc, char* argv[])
{
int f;
int j, k, t;
int y[N], z[N];
if(2 != argc)
{
printf("supply one argument chosen from 0 1 2 3\n");
return EXIT_FAILURE;
}
f = *argv[1] - '0';
if(0 == f)
printf("random\n");
else if(1 == f)
printf("sorted ascending\n");
else if(2 == f)
printf("sorted descending\n");
else
printf("identical\n");
for(j = 0; j < N; ++j)
{
t = rand() - RAND_MAX / 2;
if(0 == f)
y[j] = t;
else if(1 == f)
y[j] = j - N / 2;
else if(2 == f)
y[j] = N / 2 - j;
else
y[j] = 0;
}
for(k = 0; k < 100; ++k)
{
memcpy(z, y, N * sizeof z[0]);
qsort(z, N, sizeof z[0], compare);
}
return EXIT_SUCCESS;
}
C:/tmp[0]$elapsed_time ./a 0
random
Elapsed time: 4369 milliseconds
C:/tmp[0]$elapsed_time ./a 1
sorted ascending
Elapsed time: 2210 milliseconds
C:/tmp[0]$elapsed_time ./a 2
sorted descending
Elapsed time: 2728 milliseconds
C:/tmp[0]$elapsed_time ./a 3
identical
Elapsed time: 383 milliseconds
In accordance with what you say.
Thanks--I'll stop spreading that meme.
Results with the BSD function
(I changed 'inline' to '__inline__'):
C:/tmp[0]$elapsed_time ./a 0
random
Elapsed time: 4667 milliseconds
C:/tmp[0]$elapsed_time ./a 1
sorted ascending
Elapsed time: 949 milliseconds
C:/tmp[0]$elapsed_time ./a 2
sorted descending
Elapsed time: 1319 milliseconds
C:/tmp[0]$elapsed_time ./a 3
identical
Elapsed time: 390 milliseconds
In the tests with sorted data, it's
a little more than twice as fast as
the msvcrt qsort; in the other tests,
it's just about as fast.
|
|
From: pascal barbedor <pascalbarbedor@fr...> - 2003-05-13 05:55:52
|
hi sorry for naive question but what is the use of the mingw runtime library ? functions not provided by c standard library ? and where is the documentation about these functions ? I cant find it in the docs . thanks pascal |
|
From: Earnie Boyd <earnie_boyd@ya...> - 2003-05-13 10:56:22
|
pascal barbedor wrote: > hi > > sorry for naive question but what is the use of the mingw runtime library ? > functions not provided by c standard library ? > > and where is the documentation about these functions ? > I cant find it in the docs . > http://msdn.microsoft.com/library/shared/deeptree/asp/deeptreedl.asp?dtcfg=/library/deeptreeconfig.xml&id=vccore982578&xmlsrc=/library/en-us/toc/vccore98/vccore982578_.xml Earnie. |