[Cegcc-devel] winbase.h thread priority defines (patch)
Hi Guys, We've noticed there is some difference between thread priority defines in cegcc's winbase.h header compared to the MS WinCE SDK version. This had a significant impact on the apparent performance of our software where new threads were being created using the win32 values. Here's the suggested patch:- --- cegcc/src/w32api/include/winbase.h (revision 1069) +++ cegcc/src/w32api/include/winbase.h (working copy) @@ -258,6 +258,16 @@ #define GET_TAPE_DRIVE_INFORMATION 1 #define SET_TAPE_MEDIA_INFORMATION 0 #define SET_TAPE_DRIVE_INFORMATION 1 +#ifdef _WIN32_WCE +#define THREAD_PRIORITY_TIME_CRITICAL 0 +#define THREAD_PRIORITY_HIGHEST 1 +#define THREAD_PRIORITY_ABOVE_NORMAL 2 +#define THREAD_PRIORITY_NORMAL 3 +#define THREAD_PRIORITY_BELOW_NORMAL 4 +#define THREAD_PRIORITY_LOWEST 5 +#define THREAD_PRIORITY_ABOVE_IDLE 6 +#define THREAD_PRIORITY_IDLE 7 +#else #define THREAD_PRIORITY_ABOVE_NORMAL 1 #define THREAD_PRIORITY_BELOW_NORMAL (-1) #define THREAD_PRIORITY_HIGHEST 2 @@ -265,6 +275,7 @@ #define THREAD_PRIORITY_LOWEST (-2) #define THREAD_PRIORITY_NORMAL 0 #define THREAD_PRIORITY_TIME_CRITICAL 15 +#endif #define THREAD_PRIORITY_ERROR_RETURN 2147483647 #define TIME_ZONE_ID_UNKNOWN 0 #define TIME_ZONE_ID_STANDARD 1 -- Matt. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Re: [Cegcc-devel] winbase.h thread priority defines (patch)
Matthew Kille wrote: > Here's the suggested patch:- Good thing it's documented: http://msdn2.microsoft.com/en-us/library/ms834197.aspx I also needed this for: http://sourceware.org/ml/gdb-patches/2007-11/msg00218.html I can confirm it makes a difference :-) Will commit your patch when I get home. Thanks! -- Pedro Alves __ Sabe quanto gasta com a sua ligação à Internet? Verifique aqui: http://acesso.portugalmail.pt/contas - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Re: [Cegcc-devel] winbase.h thread priority defines (patch)
At http://msdn2.microsoft.com/en-us/library/ms913056.aspx it is stated that "All threads initially start at THREAD_PRIORITY_NORMAL (251)." Currently I use CeSetThreadPriority(GetCurrentThread(), priority); where priority is between 248 and 254 to run threads in background. If I remember well, this priority value has changed between WinCE versions. So I hope everything is ok with this patch. Pascal Matthew Kille a écrit : > Hi Guys, > > We've noticed there is some difference between thread priority defines > in cegcc's winbase.h header compared to the MS WinCE SDK version. This > had a significant impact on the apparent performance of our software > where new threads were being created using the win32 values. > > Here's the suggested patch:- > > --- cegcc/src/w32api/include/winbase.h(revision 1069) > +++ cegcc/src/w32api/include/winbase.h(working copy) > @@ -258,6 +258,16 @@ > #define GET_TAPE_DRIVE_INFORMATION 1 > #define SET_TAPE_MEDIA_INFORMATION 0 > #define SET_TAPE_DRIVE_INFORMATION 1 > +#ifdef _WIN32_WCE > +#define THREAD_PRIORITY_TIME_CRITICAL 0 > +#define THREAD_PRIORITY_HIGHEST 1 > +#define THREAD_PRIORITY_ABOVE_NORMAL 2 > +#define THREAD_PRIORITY_NORMAL 3 > +#define THREAD_PRIORITY_BELOW_NORMAL 4 > +#define THREAD_PRIORITY_LOWEST 5 > +#define THREAD_PRIORITY_ABOVE_IDLE 6 > +#define THREAD_PRIORITY_IDLE 7 > +#else > #define THREAD_PRIORITY_ABOVE_NORMAL 1 > #define THREAD_PRIORITY_BELOW_NORMAL (-1) > #define THREAD_PRIORITY_HIGHEST 2 > @@ -265,6 +275,7 @@ > #define THREAD_PRIORITY_LOWEST (-2) > #define THREAD_PRIORITY_NORMAL 0 > #define THREAD_PRIORITY_TIME_CRITICAL 15 > +#endif > #define THREAD_PRIORITY_ERROR_RETURN 2147483647 > #define TIME_ZONE_ID_UNKNOWN 0 > #define TIME_ZONE_ID_STANDARD 1 > > -- > Matt. > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > Cegcc-devel mailing list > Cegcc-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cegcc-devel > > > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Re: [Cegcc-devel] winbase.h thread priority defines (patch)
pgeorges wrote: At http://msdn2.microsoft.com/en-us/library/ms913056.aspx it is stated that "All threads initially start at THREAD_PRIORITY_NORMAL (251)." Currently I use CeSetThreadPriority(GetCurrentThread(), priority); where priority is between 248 and 254 to run threads in background. If I remember well, this priority value has changed between WinCE versions. So I hope everything is ok with this patch. Hummm, it isn't clear if one should *always* use the 248-254 range in both SetThreadPriority and CeSetThreadPriority, or if just on the Ce* functions. I assumed that the GetThreadPriority still returned the same values as CE 2 did. That'll have to be checked with a simple GetThreadPriority on GetCurrentThread, to see if it returns a value in the range of 248-255 as said here: http://msdn2.microsoft.com/en-us/library/aa450596.aspx ... or a value in the 0-8 range. We may have to conditionalise those values with _WIN32_WCE > 2, etc... -- Pedro Alves __ Continua a preferir gastar mais? Compare o preço da sua ligação à Internet http://acesso.portugalmail.pt/compare - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
[Cegcc-devel] New binary build to be released soon?
I'm very interested in using cegcc to compile wxWinCE and I aware that patches to cegcc were already committed to svn. Any plans to release a binary build soon? Thanks, Pablo - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
[Cegcc-devel] Speed: mingw32ce vs cegcc
Dear All, I've recently fixed some C++ code so that it will compile with the mingw32ce flavour of cegcc (I've been using the "normal" cegcc with newlib before now). I was hoping to remove the dependency on the cegcc DLLs, and also speed up file opening (the app opens lots and lots of files). However, despite opening files faster (it's about twice as fast, just for the open), the rest of the program runs significantly slower when using mingw32ce (50-100% slower). I assume that the code generated for mingw and cegcc is much the same, and that any differences are mostly due to system/library calls. The app is particularly CPU and memory intensive - in fact the parts of the code that do lots of memory allocation are the parts that seem to slow down the most, and so I have reason to believe that it is something to do with the memory allocation. Does mingw32ce use a different memory allocation method to cegcc/newlib? My guess would be that mingw32ce uses the wince memory allocation directly, and that newlib might have it's own memory allocation stuff?? If so, then it seems that the newlib allocator is much more suitable for my task. Is there some way that I can use the memory allocator in newlib without having to use the rest of it? Has anyone else encountered this or have any suggestions? Am I on the right track with the memory allocation, or could this be down to something else entirely? Many thanks, Hywel. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Re: [Cegcc-devel] Speed: mingw32ce vs cegcc
Hywel B. Richards wrote: > Does mingw32ce use a different memory allocation method to cegcc/newlib? > My guess would be that mingw32ce uses the wince memory allocation > directly, and that newlib might have it's own memory allocation stuff?? > > If so, then it seems that the newlib allocator is much more suitable for > my task. Is there some way that I can use the memory allocator in newlib > without having to use the rest of it? > > Has anyone else encountered this or have any suggestions? > Am I on the right track with the memory allocation, or could this be > down to something else entirely? > Yes. cegcc uses a version of Doug Lea's malloc, while mingw32ce uses whatever's in coredll.dll. See: /src/newlib/newlib/libc/sys/wince/malloc.c You could try reusing it, and/or writing your own global operator new, operator delete, etc. However, if you find that you can isolate the parts of the code that are critical, it may be better to use a pool or a special allocator for the memory management of those time critical allocations/objects. Cheers, Pedro Alves - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Re: [Cegcc-devel] Speed: mingw32ce vs cegcc
Pedro Alves a écrit : > However, if you find that you can isolate the parts of > the code that are critical, it may be better to use a pool > or a special allocator for the memory management of those > time critical allocations/objects. > > Cheers, > Pedro Alves > > I made some tests with malloc/free and Tcl_Alloc/Tcl_Free as my application is linked with Tcl/Tk. When using a lot of malloc instead of Tcl_Alloc (which uses pools of memory), the result was very poor (high memory consumption). Pascal - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Re: [Cegcc-devel] New binary build to be released soon?
Pablo Rogina wrote: > I'm very interested in using cegcc to compile wxWinCE and I aware that > patches to cegcc were already committed to svn. > > Any plans to release a binary build soon? > I'm OK with releasing a 0.6. I don't think we have any show stoppers. We've had an ABI change to make us (more) compatible with MSVC on trunk, and a few nice w32api/* fixes. Danny, what say you? Cheers, Pedro Alves - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Re: [Cegcc-devel] my CeGCC FAQ
Jacek M. Holeczek wrote: > please find attached my vision of the "official CeGCC FAQ". > Please make it public on the CeGCC web page. > If you don't agree with its form (i.e. you think the "official FAQ" > should look different), please make it public anyhow, just name > it "Jacek's CeGCC FAQ". > Hope it helps, > Best regards, > Jacek. > Sorry that noone has commented on this yet. I still haven't been able to read it, but I've been meaning to. What would you think of putting these kinds of things in (currently empty) cegcc's wiki? http://cegcc.wiki.sourceforge.net Cheers, Pedro Alves - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Re: [Cegcc-devel] winbase.h thread priority defines (patch)
Pedro Alves wrote:
> pgeorges wrote:
>
> At http://msdn2.microsoft.com/en-us/library/ms913056.aspx
> it is stated that
> "All threads initially start at THREAD_PRIORITY_NORMAL (251)."
>
> Currently I use
> CeSetThreadPriority(GetCurrentThread(), priority);
> where priority is between 248 and 254 to run threads in background.
>
> If I remember well, this priority value has changed between WinCE versions.
> So I hope everything is ok with this patch.
>
> Hummm, it isn't clear if one should *always* use the 248-254
> range in both SetThreadPriority and CeSetThreadPriority, or if
> just on the Ce* functions.
>
> I assumed that the GetThreadPriority still returned the
> same values as CE 2 did. That'll have to be checked
> with a simple GetThreadPriority on GetCurrentThread, to see if it
> returns a value in the range of 248-255 as said here:
> http://msdn2.microsoft.com/en-us/library/aa450596.aspx
>
> ... or a value in the 0-8 range.
>
> We may have to conditionalise those values with _WIN32_WCE > 2, etc...
>
Well, someone should send MSFT a doc patch :)
this:
#include
#include
int main ()
{
HANDLE h = GetCurrentThread ();
int prio = GetThreadPriority (h);
int prio2 = CeGetThreadPriority (h);
int error = CeGetThreadPriority ((HANDLE)123);
printf ("prio = %d\n", prio);
printf ("prio2 = %d\n", prio2);
printf ("error = %x\n", error);
return 0;
}
... prints:
prio = 3
prio2 = 251
error = 0x7fff
(I was also curious to see if we already have
THREAD_PRIORITY_ERROR_RETURN right -- we do)
I've checked Matt's patch in.
Cheers,
Pedro Alves
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
