Re: [Harbour] hbrun and mt
Przemyslaw,
yes! with fm statistics off it works wonderfully :)
Thanks so much.
Maurilio.
Przemyslaw Czerpak wrote:
> On Wed, 24 Sep 2008, Maurilio Longo wrote:
>
> Hi Maurilio,
>
>> I'm not completely sure I do understand the way the pre-loading of the stack
>> gets done, but I think it ends up in creating a variable in every C function
>> which needs access to the stack.
>
> Exactly.
>
>> Now,
>> int f()
>> {
>> HB_STACK_TLS_PRELOAD
>> }
>> becomes (more or less)
>> int f()
>> {
>> PULONG hb_stack_ptr = hb_tls_get( hb_stack_key );
>> }
>> where hb_stack_key is an index in win32 but the real memory address in OS/2.
>> So, when in win32 you call TlsGetValue( hb_stack_key ) you ask for the
>> content
>> of that slot of memory, but when you call DosAllocThreadLocalMemory( 1, &k ),
>> 1 means you need a single DWORD, &k will contain the address of that DWORD
>> which is local to your thread.
>
> Yes it is. Read my message to David. It will not give noticeable speed
> difference in OS2 because it only safes one memory access. Just like
> in my Linux box where I can use C compiler TLS support.
>
>> So, when every function calls hb_tls_get() in OS/2, you simply get back what
>> you passed to it,
>
> Exactly.
>
>> which is not the original pointer you got with
>> DosAllocThreadLocalMemory() since the first call did not save it somewhere.
>
> No, it saved it. It's done in hb_stackInit() which should be the first
> function whichop operates on allocated TLM. Then it's safe to call
> HB_STACK_TLS_PRELOAD.
> But I think you just help me to find the reason of problem.
>
>> Maybe I'm just confused by too many macros and I'm simply missing the real
>> way
>> in which this should work, but after a few hours looking at this problem I
>> cannot understand what is not working.
>> Can you please confirm what I've said or explain to me how pre-loading is
>> intended to work?
>
> I think that the problem is caused by hb_xgrab(). You probably uses memory
> statistics enabled in your Harbour builds and David disabled them and
> this is the reason why it works for him but not for you. I think that
> if you recompile Harbour with -DHB_FM_STATISTICS_OFF then it will work
> Just simply I made a typo in hb_stackBaseProcInfo() which is called by
> memory statistic module from hb_xgrab() which is used before HVM starts
> to register .prg modules. HB_STACK_TLS_PRELOAD should be used _after_
> hb_stack_ready() in this function. I'll commit fix in a while.
> Thank you very much for your help.
>
> best regards,
> Przemek
> ___
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-09-24 18:17 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
Szakáts Viktor a écrit : 2008-09-24 18:17 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * utils/hbdoc/hbdoc.prg * utils/hbmake/hbmake.prg * utils/hbrun/hbrun.prg % One function made STATIC. Thank you Viktor & Przemek. Can we get this for 1.0.2 ? Guy ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbrun and mt
On Thu, 25 Sep 2008, Maurilio Longo wrote: Hi Maurilio, > yes! with fm statistics off it works wonderfully :) Thank you for confirmation. Now it should work also with memory statistic enabled. When we will make some other test then I'll disable stack preloading for this systems and C compilers when it does not give any valuable speed improvement. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Feature Request SF#2122754: Trigger on variable change
It can be very useful, we need to do it manually :(
in our ERP need to spread some values on changing variables, and
the tree some times is very long and easy to break, we now are using
codeblocks that are evaluated overloading assign operator.
Is an important feature to ERP developers.
Trigger can be better solution, because only one variable is overloaded.
Best regards,
Miguel Angel Marchuet
Przemyslaw Czerpak escribió:
On Wed, 24 Sep 2008, Chen Kedem wrote:
is it possible for you to implement a "data trigger" (for vars, fields,
object and so on) defining a code block called when the object changes his
value...
example of code
function main()
local nvar as numeric
nvar := 1
//
// set trigger (for example)
//
_set_trigger("nvar",{|cName,Value| qout(cName+" new value:"+str(Value)}
// trigger is called immediately after nvar value change
nvar++
return NIL
result:
NVAR new value: 2
For simple vars there is no such functionality at .prg level though
it's be quite easy to implement it in C using existing functionality.
We even already use such mechanism in few places, f.e. for thread local
static variables or SETGET object method references. I do not find it
enough usable to create public .prg interface for it but it's possible
and if more people will request for it and group agree I can implement
it.
For DBFs it's possible to set triggers executed on each fields access/
assign using SIX3 interface.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
__ Informaci�n de ESET NOD32 Antivirus, versi�n de la base de firmas de
virus 3469 (20080924) __
ESET NOD32 Antivirus ha comprobado este mensaje.
http://www.eset.com
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: hbrun and mt
Przemek, Maurilio: [Maurilio] yes! with fm statistics off it works wonderfully :) [Przemek] Thank you for confirmation. Now it should work also with memory statistic enabled. When we will make some other test then I'll disable stack preloading for this systems and C compilers when it does not give any valuable speed improvement. I made a fresh build without -DHB_FM_STATISTICS_OFF -- set HB_ARCHITECTURE=os2 set HB_COMPILER=gcc set HB_GT_LIB= rem set PRG_USR= rem set C_USR= Rem set C_USR=-DHB_LONG_LONG_OFF Rem set C_USR=-DHB_FM_STATISTICS_OFF -DHB_FM_DL_ALLOC Rem set C_USR=-DHB_FM_STATISTICS_OFF set L_USR=-Le:\usr\lib\tcpipv4 rem set C_USR=-DTCPV40HDRS %C_USR% Rem set HB_OS2_NEW_TCP=yes -- and Harbour build/run fine Creating / running hbrun_mt.exe with mttest01.prg: - [E:\harbour809mt\harbour\tests]e:\harbour809mt\harbour\bin\hbrun_mt.exe mt\mttest01.prg Harbour 1.1.0dev (Rev. 9501) join: .T. result: Hello World!!! Hello World!!! Hello World!!! static var type: B 12345.678 12346.678 - It does not raise error reported by Maurilio: I did the change to the makefile, I get an immediate SIGSEGV simply starting hbrun. (E:\repository\harbour-svn\tests)\harbour\bin\hbrun mt\mttest01.prg Killed by SIGSEGV so real problem with Maurilio build remain unknown, but is affected by HB_FM_STATISTICS_OFF David Macias ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Feature Request SF#2122754: Trigger on variable change
Hi all,
For simple variables I find this an odd feature,
might be even dangerous and may also affect
performance. Not to mention how many odd cases
it may generate (think of recursion if the trigger
block modifies the triggering variable, variables
referencing other variables, and handling arrays
- even embedded ones, let alone objects).
Also, for variables a very easy and proper alternate
solution is to use simple set/get methods/functions,
and hiding the variable as hidden object var or simple
static var.
For fields it might be useful though, but as Przemek
says, we already have it.
Brgds,
Viktor
On 2008.09.24., at 21:18, Chen Kedem wrote:
This submitted to the Harbour SF as feature request (I just forward
it as is)
https://sourceforge.net/tracker/index.php?func=detail&aid=2122754&group_id=681&atid=350681
-
is it possible for you to implement a "data trigger" (for vars,
fields,
object and so on) defining a code block called when the object
changes his
value...
example of code
function main()
local nvar as numeric
nvar := 1
//
// set trigger (for example)
//
_set_trigger("nvar",{|cName,Value| qout(cName+" new
value:"+str(Value)}
// trigger is called immediately after nvar value change
nvar++
return NIL
result:
NVAR new value: 2
-
Chen.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
On Wed, 24 Sep 2008, Szak�ts Viktor wrote: Hi all, > I've built mingw with -DHB_USE_TLS (the rest is default), > then I got 'undefined reference to '__emutls_get_address' > errors on linking. Such symbol doesn't BTW exist in MinGW > 4.3.2 supplied libs. AFAIR the work on TLS support for MinGW started at the begining of summer so probably you should look at newest MinGW versions (probably devel ones if you want to use it). > Here are some Windows compiler comparison results > (speedtst / Total application time) > = > 1.1.0 (r9488) > - -DHB_NO_DEBUG [ -DHB_NO_TRACE is default ] -DHB_FM_STATISTICS_OFF > -DHB_FM_DL_ALLOC > - Harbour: -l -gc3 [I didn't mean to test with -gc3, but I had it there for > production, and forgot about it] It may has some indirect impact on CPU cache efficiency. Not big but noticeable in tests. > - MSVS switches: (all default C mode) > - GCC switches: -O3 -fomit-frame-pointer -ffast-math -march=pentiumpro > - BCC switches: -6 -OS -Ov -Oi -Oc -Q -tWM -ffast-math in some cases increases the differences in FL arithmetic so not all people like it. I also suggest to check -march=pentiumpro. This CPU has extremely slow 16bit registers and it's possible that MinGW will try to make some workarounds for it but I do not know if it really does it. Anyhow I rather suggest to chose something more closer to hardware you are using if you want to enable CPU optimization. > Compiler ST MT overhead > -- -- > MSVS2008 32.41 46.09 42% > GCC43246.58 66.02 41% [NOTE: GCC doesn't have TLS support AFAIK] > BCC58 52.64 72.75 38% > 1.0.1 (release) > - -DHB_NO_DEBUG -DHB_NO_TRACE [ -DHB_FM_STATISTICS_OFF is default ] > - Rest of switches same as above. > Compiler ST > -- > MSVS2008 41.06 > GCC43253.25 > BCC58 52.80 In all this tests memory manager has the most important impact so it's hard to well compare the results. I noticed in the past that Windows is extremly slow in comparision to other OSes when process has to allocate/free memory pages. It probably strictly depends on Windows version but I'm not Windows guru to say which versions works better/worse. Here the MSVC results are the best but I'm not sure it's caused by better code only. I think that OpenWatcom with its default MM will give you also such good results. If you can please check it on the same machine. > Basically I'm getting a consistent 36-42% MT overhead with all > compilers, so I wouldn't be surprised if overhead would highly > depend on exact CPU model and maybe Windows version. The cost of TLS access is strictly compiler/OS dependent. I've just make interesting experiment to compare the code of using stack pointer to dynamically allocated stack instead of statick stack address in ST programs. I made very simple modificatrion. In hbstack.c for ST mode I changed: extern HB_STACK hb_stack; to: extern PHB_STACK hb_stack_ptr; # define hb_stack ( * hb_stack_ptr ) and in estack.c: # if defined( HB_STACK_MACROS ) HB_STACK hb_stack; # else static HB_STACK hb_stack; # endif to: HB_STACK _hb_stack_; PHB_STACK hb_stack_ptr = &_hb_stack_; Then I recompiled HVM. The results are realy interesting: With original HVM I have: ST: total application time: 27.80 MT: total application time: 30.79 with modified one: ST: total application time: 32.09 MT: total application time: 30.93 The modification was only for ST mode so MT results are the same. But in ST mode it nicely shows the overhead of using pointer to stack instead of it direct address which can be optimized by compiler. In GCC build it's _bigger_ then native TLS access with enabled buffering. Without buffering the results are in practice the same. Probably buffering in local C function variable allows to enable some additional optimization because GCC does not have to worry that it will be change by some external function calls. It means that we already reach the same speed level as in ST mode if compiler has fast TLS access. In Current Linux and GCC versions using TLS does not have any noticeable speed impact. The same is in OS2. For us this is zero cost. The results are the same and the overhead ~10-20% is caused by different data structures which does not allow to enable optimizations possible for statically allocated HB_STACK structure. It also means that we will not improve the speed if we begin to pass the pointer to HB_STACK between functions as parameter. The problem is only with systems where TLS access is really expensive. F.e. older Linuxes, some *nixes, some systems without TLS at all where we will have to emulate it ourselves and looks that also in Windows though here I'm not such sure the results for compilers with native TLS support. At least few o
Re: [Harbour] Re: hbrun and mt
On Thu, 25 Sep 2008, David Arturo Macias Corona wrote: Hi David, > I made a fresh build without -DHB_FM_STATISTICS_OFF > and Harbour build/run fine Thank you very much for test. > It does not raise error reported by Maurilio: > >>> I did the change to the makefile, I get an immediate SIGSEGV simply >>> starting hbrun. >>> (E:\repository\harbour-svn\tests)\harbour\bin\hbrun mt\mttest01.prg >>> Killed by SIGSEGV > > so real problem with Maurilio build remain unknown, but is affected by > HB_FM_STATISTICS_OFF No. it's known. I fixed it at: 2008-09-24 20:30 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) and it's the reason why it's working for you now. It was real bug. Once again thank you very much for your help. Now MT for OS2 seems to be fully functional and works well. Some minor things can be cleaned yet but they are not big problem. Have you agreed final version for TCPV40HDRS / HB_OS2_TCP32 best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-09-25 11:26 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-09-25 11:26 UTC+0200 Viktor Szakats (harbour.01 syenar hu) - harbour-ce-spec + harbour-wce-spec - harbour-w32-spec + harbour-win-spec - make_rpmw32.sh + make_rpmwin.sh - make_rpmce.sh + make_rpmwce.sh * Some steps done to use more consistent names for Windows and Windows CE, and also to move away from '32' usage. ; TODO: I'd prefer to give all .spec files the same empty extensions, could anyone help how to convert current harbour.spec to harbour-spec and not break .rpm creation? Plus it would be also good to implement automatic versioning on .rpm build just like for harbour-win/wce in make_rpmw*.sh scripts. - hbgtmk.sh + make_rpm_from_svn.sh * Renamed to give a better idea about its purpose. ; NOTE: make_rpm_from_svn.sh seems a bit pointless now that we have the final releases in separate SVN tags. * make_gcc.mak * Minor formatting. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbrun and mt
Przemyslaw, > Have you agreed final version for TCPV40HDRS / HB_OS2_TCP32 I think yes, let's wait for David confirmation, anyway HB_OS2_TCP32 is more meaningfull since it pinpoints what it is changing. Thanks. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: 2008-09-18 01:17 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Przemyslaw Czerpak wrote: > Thank you very much for the information. It means that dlmalloc.c > will have to be updated to use native OS2 API in the future if it > works as expected for Windows users. > Probably you are the best person to make it in such case :-) > Przemyslaw, I was looking at dlmalloc, so I decided to try the test program from Pritpal (message of september, 18th), on OS/2, latest cvs code, hbrun with vmmt linked in I can add nearly 816000 items before I get a realloc error. 809000 81 811000 812000 813000 814000 815000 816000 Unrecoverable error 9009: hb_xrealloc can't reallocate memory Called from AADD(0) Called from MAIN(6) in pcode.hrb Called from HB_HRBRUN(0) Called from _APPMAIN(114) in ../../hbrun.prg Now it has to be said that on OS/2 a program can allocate a maximum of 512Mb (actually you top around 450-500Mb) because this is the virtual address space assigned to each process. It is possible to use more memory calling specific APIs, but a pointer to a block into this memory, called 'high memory', cannot be passed to all OS/2 APIs. So it is of limited use. That said, I think that porting dlmalloc to OS/2 is a waste of time without, probably, any real advantage in terms of speed or stability (I see from dlmalloc.c that it is not well suited for mt programs since it uses a global lock which can become the bottleneck). Those above are my two cents :) Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: hbrun and mt
Przemek, Maurilio: >>Once again thank you very much for your help. Now MT for OS2 >>seems to be fully functional and works well. Some minor things >>can be cleaned yet but they are not big problem. >>Have you agreed final version for TCPV40HDRS / HB_OS2_TCP32 >I think yes, let's wait for David confirmation, anyway HB_OS2_TCP32 is >more meaningfull since it pinpoints what it is changing. Yes Iam agree, it look better Please add in gcc.cf a comment for -DTCPV40HDRS based on: --- v3.2.2 Alpha 2: --- A few bugfixes and a couple of new features. o The TCP/IP headers and libraries scheme have been changed. The default is the current OS/2 tcpip toolkit (BSD 4.4 based). To target the older OS/2 tcpip stack (BSD 4.3 based) you must define TCPV40HDRS before including any TCP/IP headers and make sure usr/lib/tcpipv4 is searched before usr/lib (this is to get the right libsocket). It is recommended to use the -D compiler option for the define and either the LIBRARY_PATH or the -L compiler/linker option for the library. --- As Maurilio explained earlier, setting -DTCPV40HDRS does not complete all the work if tcpipv4 libraries are not forced, as example: --- set L_USR=-Le:\usr\lib\tcpipv4 --- David Macias ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: 2008-09-18 01:17 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Maurilio, David, Unrecoverable error 9009: hb_xrealloc can't reallocate memory Called from AADD(0) Called from MAIN(6) in pcode.hrb Called from HB_HRBRUN(0) Called from _APPMAIN(114) in ../../hbrun.prg Do I see well, that in OS/2 a stack trace looks always misaligned as above? This, and also plain usage of \r in Windows, should IMO be fixed. Dunno what's the best way to make these EOLs fully portable though. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-09-25 11:26 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
On Thu, 25 Sep 2008, Szak�ts Viktor wrote: Hi Viktor, > 2008-09-25 11:26 UTC+0200 Viktor Szakats (harbour.01 syenar hu) > * Some steps done to use more consistent names for Windows > and Windows CE, and also to move away from '32' usage. > ; TODO: I'd prefer to give all .spec files the same > empty extensions, could anyone help how to > convert current harbour.spec to harbour-spec and > not break .rpm creation? Plus it would be also It will break one feature. Now you can download harbour-*.src.tar.gz and use: rpmbuild -ta harbour-*.src.tar.gz and RPM automatically extracts *.spec file(s) and use then to create RPM package. It's the reason why only one (native) file has .spec extension. Of course we can drop such functionality. > good to implement automatic versioning on .rpm > build just like for harbour-win/wce in make_rpmw*.sh > scripts. The problem is with above functionality. The file has to be packed with valid number. > - hbgtmk.sh > + make_rpm_from_svn.sh > * Renamed to give a better idea about its purpose. > ; NOTE: make_rpm_from_svn.sh seems a bit pointless now > that we have the final releases in separate SVN tags. IMHO it's enough to update it in each branch. I was looking for such keyword in SVN documentation to make the url updating automatic but I was not able to find anything like that :-( best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: 2008-09-18 01:17 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Viktor, not always, I mean, if I press Alt-C stack trace is ok. If I call hbrun speedtst.prg, output is misaligned. Maurilio. Szakáts Viktor wrote: >> > Hi Maurilio, David, > >> Unrecoverable error 9009: hb_xrealloc can't reallocate memory >> Called from AADD(0) >> Called from MAIN(6) in pcode.hrb >> Called from >> HB_HRBRUN(0) >> >> Called from _APPMAIN(114) in ../../hbrun.prg > > Do I see well, that in OS/2 a stack trace looks > always misaligned as above? > > This, and also plain usage of \r in Windows, should > IMO be fixed. Dunno what's the best way to make these > EOLs fully portable though. > > Brgds, > Viktor > > ___ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] A few questions about MT
Viktor and Przemyslaw, +1 for a way to be fully xbase++ compatible. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-09-25 11:26 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
Hi Przemek, empty extensions, could anyone help how to convert current harbour.spec to harbour-spec and not break .rpm creation? Plus it would be also It will break one feature. Now you can download harbour-*.src.tar.gz and use: rpmbuild -ta harbour-*.src.tar.gz and RPM automatically extracts *.spec file(s) and use then to create RPM package. It's the reason why only one (native) file has .spec extension. Of course we can drop such functionality. good to implement automatic versioning on .rpm build just like for harbour-win/wce in make_rpmw*.sh scripts. The problem is with above functionality. The file has to be packed with valid number. Okay, now I understand. I can't judge how important this feature is really for .rpm users, or if its used or not by anyone, so we may just leave it. It'd be better to have them aligned, because they need to be update together in 99% of cases, and currently it's very easy to forget about the others. - hbgtmk.sh + make_rpm_from_svn.sh * Renamed to give a better idea about its purpose. ; NOTE: make_rpm_from_svn.sh seems a bit pointless now that we have the final releases in separate SVN tags. IMHO it's enough to update it in each branch. I was looking for such keyword in SVN documentation to make the url updating automatic but I was not able to find anything like that :-( Hm, I still don't really see the purpose of this script. To build the same version from SVN, as the source distribution this file come from, well, I can't see why it could be useful. If the purpose is to be able to build a recent devl version from official source distribution, the current SVN URL is fine. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-09-22 02:34 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Przemyslaw, why thread 1 does not have TID? I think that all .prg thread should be equal :) so that we can handle them the same way. Best regards. Maurilio. Przemyslaw Czerpak wrote: > 2008-09-22 02:34 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/include/hbvm.h > * harbour/source/vm/hvm.c > * harbour/source/vm/thread.c > + added .prg function hb_threadSelf() -> | NIL > It returns thread ID pointer variable or NIL when thread was > registered without it (main thread and some 3-rd party threads > created by C API) > > * harbour/source/vm/hvm.c > * protect s_InitFunctions and s_ExitFunctions by mutex > > * harbour/source/common/hbverdsp.c > * use hb_verBuildDate() instead of __DATE__ and __TIME__ in > hb_verBuildInfo() function to report the same time in both > cases. > > best regards > Przemek > ___ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
Hi Przemek, I've built mingw with -DHB_USE_TLS (the rest is default), then I got 'undefined reference to '__emutls_get_address' errors on linking. Such symbol doesn't BTW exist in MinGW 4.3.2 supplied libs. AFAIR the work on TLS support for MinGW started at the begining of summer so probably you should look at newest MinGW versions (probably devel ones if you want to use it). Despite my 'GCC432' markings, this was actually done with the latest stable MinGW, which is 4.1.2, so I'll make some tests with the latest available 4.3.2 non-official build, maybe it already has it. [ Update: Tried MinGW 4.3.2 with -DHB_USE_TLS, and I'm still getting the same error as above. Maybe I'm doing something wrong, which could well may be given the zillions of factors involved. ] - MSVS switches: (all default C mode) - GCC switches: -O3 -fomit-frame-pointer -ffast-math - march=pentiumpro - BCC switches: -6 -OS -Ov -Oi -Oc -Q -tWM -ffast-math in some cases increases the differences in FL arithmetic so not all people like it. I also suggest to check -march=pentiumpro. This CPU has extremely slow 16bit registers and it's possible that MinGW will try to make some workarounds for it but I do not know if it really does it. Anyhow I rather suggest to chose something more closer to hardware you are using if you want to enable CPU optimization. Okay and thanks, I'll simply remove both, as the .exe ought to run on not just my system, but possibly on all hardware my app may run (when I begin to use GCC live). I also removed -ffast-math from future official MinGW builds. [ Update: After removing both from 1.0.1 builds, I got _just slightly_ bigger binaries, and about identical performance. As a downside, now I'm getting 44 errors in hbtest, due to failing Round() and Int() tests: 914, 917-920, 923-925, 959, 962-965, 968-970, 987-990. Actually the new MinGW results are the right ones, but the expected results seem to be screwed up, showing 705032704 instead of 50. Quite strange. ] It also means that we will not improve the speed if we begin to pass the pointer to HB_STACK between functions as parameter. The problem is only with systems where TLS access is really expensive. F.e. older Linuxes, some *nixes, some systems without TLS at all where we will have to emulate it ourselves and looks that also in Windows though here I'm not such sure the results for compilers with native TLS support. At least few of then should give better performance. The speed difference is simply too huge. I also made some tests but I run MinGW and BCC programs in my Linux box using WINE and the overhead is from 25% to 32%. BTW. Viktor if possible then I would like to send you MinGW binaries to compare results on your system with your native MinGW builds. Okay, no problem. [ As for OpenWatcom tests, maybe a bit later, I'd personally rather choose the best from the mainstream compilers. ] [ Lucky Linux/OS/2 users, I didn't expect Windows to suck this much. Having said all that, maybe it'd just fine to enable MT by default on those systems where there is no extra overhead beyond the one caused by different C structures. ] Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: 2008-09-18 01:17 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Viktor:
>> Unrecoverable error 9009: hb_xrealloc can't reallocate memory
>> Called from AADD(0)
>> Called from MAIN(6) in pcode.hrb
>> Called from
>> HB_HRBRUN(0)
>>
>> Called from _APPMAIN(114) in ../../hbrun.prg
>Do I see well, that in OS/2 a stack trace looks
>always misaligned as above?
>This, and also plain usage of \r in Windows, should
>IMO be fixed. Dunno what's the best way to make these
>EOLs fully portable though.
[Maurilio]
>not always, I mean, if I press Alt-C stack trace is ok.
>If I call hbrun speedtst.prg, output is misaligned.
In stack trace happen as Viktor said
In speedtst.prg is due to:
--
#ifndef EOL
#define EOL chr(10)
#endif
#command ? => outstd(EOL)
#command ? => outstd(, EOL)
--
Speedtst.prg produce this kind of output:
--
f2(c[4]); c2:=c ->
0.41
f2(@c[4]); c2:=c ->
0.39
f3(a,a2,c,i,j,t,bc) ->0.74
f2(a2) ->
0.31
s:=f4() ->
1.84
s:=f5() ->
1.04
ascan(a,i%ARR_LEN) -> 0.93
ascan(a2,c+chr
(i%64+64)) -> 3.02
ascan(a,{|x|x==i%ARR_LEN}) ->
7.67
total application time: 57.53
total
real time:
57.53
--
David Macias
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: 2008-09-18 01:17 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Thu, 25 Sep 2008, Maurilio Longo wrote: Hi Maurilio, > > Thank you very much for the information. It means that dlmalloc.c > > will have to be updated to use native OS2 API in the future if it > > works as expected for Windows users. > > Probably you are the best person to make it in such case :-) > I was looking at dlmalloc, so I decided to try the test program from Pritpal > (message of september, 18th), on OS/2, latest cvs code, hbrun with vmmt linked > in I can add nearly 816000 items before I get a realloc error. > 809000 > 81 > 811000 > 812000 > 813000 > 814000 > 815000 > 816000 > Unrecoverable error 9009: hb_xrealloc can't reallocate memory > Called from AADD(0) >Called from MAIN(6) in pcode.hrb >Called from HB_HRBRUN(0) > Called from _APPMAIN(114) in ../../hbrun.prg > Now it has to be said that on OS/2 a program can allocate a maximum of 512Mb > (actually you top around 450-500Mb) because this is the virtual address space > assigned to each process. The problem is that this code _ALLOCATES_ such huge amount of memory when in fact it needs much more. It's caused by uneficient memory manager. When this program finish after 1'000'000 iterations then MEMORY( HB_MEM_USEDMAX ) shows 48'176'447. This is totatl memory allocated by Harbour. The rest is MM overhead. Memory conservative MM should not allocate more then ~twice memory ~ 100MB. Good MM with automatic preallocation for future resising but also tuned to safe memory should allocate about three times more memory ~150MB. In my Linux box for such test it's 144MB. _Exactly_ 3 times more (classic algorithm). And results are very close to DL-MM results. The default MM in GCC for OS2 is not clever enough to rach such results and allocates much more memory then necessary probably also highly reducing performance because it suggest that array resize (AADD()) forces two often phisical memory realloction of array body to newly alocated blocks. > It is possible to use more memory calling specific APIs, but a pointer to a > block into this memory, called 'high memory', cannot be passed to all OS/2 > APIs. So it is of limited use. OK, fine. Each OS has such limit. F.e. to speed up Linux system you can limit maximum process memory to 1GB and in such case system can use fixed addreses for kernel and user space so switchin between them (calling any kernel level function) does not force memory descriptor overloading. Very nice feature which give real high speed imporvement. But it's not the problem we are talking about. The real problem is that MM you used allocated more then ~150 of physical memory for this _whole_ test. In the place where it fails for you DL-MM should not need more then ~120MB. > That said, I think that porting dlmalloc to OS/2 is a waste of time without, > probably, any real advantage in terms of speed or stability (I see from > dlmalloc.c that it is not well suited for mt programs since it uses a global > lock which can become the bottleneck). > Those above are my two cents :) I think that you haven't noticed where is the problem and you take wrong conclusions. The MM behavior is also important for us to take decision about out own prealocations, f.e. in array add. Looks that good MM can made it very efficiently respecting also other memory requirements so we do not have to implement it ourselves for only chosen things, f.e. arrays body reducing the MM choices. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
Hi Przemek, [ Update: Tried MinGW 4.3.2 with -DHB_USE_TLS, and I'm still getting the same error as above. Maybe I'm doing something wrong, which could well may be given the zillions of factors involved. ] I did something wrong. Too much compilers and compiled environments on one computer... So, with 4.3.2 TLS is working. Let's see the results: App Real MT-412: 65.05 65.52 MT-432: 64.73 65.34 ST-412: 45.19 45.69 ST-432: 40.77 41.11 I conclude that TLS support in 4.3.2 is pretty good to enhance ST performance, and gives a very small advantage in MT mode. [ 4.3.2 tests were done with r9502, 4.1.2 ones with r9488, but with identical features, except TLS. ] Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-09-25 13:07 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-09-25 13:07 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * include/hbthread.h + Enabled HB_USE_TLS for MinGW >= 4.3.0 -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-09-25 13:13 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-09-25 13:13 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * tests/speedtst.prg ! Use hb_OSNewLine() instead of hard-wired EOL. + Emulate hb_OSNewLine() for non-Harbour compilers. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-09-25 13:16 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-09-25 13:16 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * contrib/xhb/hbcompat.ch + Added xhb_CopyFile() two-way translations. (untested) -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-09-25 13:28 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-09-25 13:28 UTC+0200 Viktor Szakats (harbour.01 syenar hu) - make_tgz.sh + mpkg_tgz.sh - make_deb.sh + mpkg_deb.sh - make_rpm.sh + mpkg_rpm.sh - make_rpmwce.sh + mpkg_rpm_wce.sh - make_rpmwin.sh + mpkg_rpm_win.sh - make_xmingw.sh + make_gnu_xmingw.sh - make_xmingwce.sh + make_gnu_xmingwce.sh - make_rpm_from_svn.sh + mpkg_rpm_from_svn.sh * Some renamed in the hope that it will better separate the simple build scripts (make*) from package build (mpkg*) scripts. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
On Thu, 25 Sep 2008, Szak�ts Viktor wrote: Hi Viktor, > > [ Update: After removing both from 1.0.1 builds, I got _just slightly_ > bigger binaries, and about identical performance. As a downside, now > I'm getting 44 errors in hbtest, due to failing Round() and Int() > tests: 914, 917-920, 923-925, 959, 962-965, 968-970, 987-990. > Actually the new MinGW results are the right ones, but the > expected results seem to be screwed up, showing 705032704 instead of > 50. Quite strange. ] Can you send the exact hbtest output? >> BTW. Viktor if possible then I would like to send you MinGW binaries >> to compare results on your system with your native MinGW builds. > Okay, no problem. Thank you. I'll create them in a while and send to your private email address. > [ As for OpenWatcom tests, maybe a bit later, I'd personally > rather choose the best from the mainstream compilers. ] > [ Lucky Linux/OS/2 users, I didn't expect Windows to suck this much. > Having said all that, maybe it'd just fine to enable MT by default on > those systems where there is no extra overhead beyond the one caused > by different C structures. ] In Linux it' snot such easy. You need quite new 2.6 kernels, new GLIBC and new GCC for native TLS support which works also in static binaries. Otherwise you have to use pthread_getspecific() which is much slower. I still have many installation based on 2.4 or even 2.2. I hope that older ones with 2.0 and 1.2/1.3 died with the hardware ;-) anyhow here we do not have pthreads support so it will not work. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
On Thu, 25 Sep 2008, Szak�ts Viktor wrote: Hi Viktor, >> [ Update: Tried MinGW 4.3.2 with -DHB_USE_TLS, and I'm >> still getting the same error as above. Maybe I'm doing >> something wrong, which could well may be given the zillions >> of factors involved. ] > I did something wrong. Too much compilers and compiled > environments on one computer... > So, with 4.3.2 TLS is working. Let's see the results: > App Real > MT-412: 65.05 65.52 > MT-432: 64.73 65.34 > ST-412: 45.19 45.69 > ST-432: 40.77 41.11 > I conclude that TLS support in 4.3.2 is pretty good > to enhance ST performance, and gives a very small > advantage in MT mode. I do not know details for MinGW TLS but it's possible that it will be imporved yet in the future, f.e. now thay can use simple function call like in BCC. Anyhow in current SVN code the cost of TLS is quite efficient hidden by HB_STACK_PRELOAD. Just try to remove: #define HB_STACK_PRELOAD fro the beginning of estack.c and hvm.c and rebuild Harbour without HB_USE_TLS. Then compare the results. If they will be the same then probably current MinGW version simply calls TlsGetValue() for native TLS access so it the same as calling this function by us. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-09-24 20:30 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Przemyslaw, latest code, OS/2 GCC, HB_FM_STATISTICS_OFF, PIV HT 3.6GHz, SMP Kernel. ST total application time: 52.85 total real time: 52.85 MT total application time: 70.91 total real time: 70.92 Best regards. Maurilio. Przemyslaw Czerpak wrote: > 2008-09-24 20:30 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/source/vm/estack.c > ! fixed stack preloading - it should be after checking if stack > exist :) > > best regards > Przemek > ___ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] A few questions about MT
On Mon, 22 Sep 2008, Szak�ts Viktor wrote: Hi all interested in PUBLIC like in xBase++ Now user can fully control the memavars inheritance even separately for public and private vars. IMHO it's very flexible and allows to use many of existing code using memvars without rewirting it for MT mode so seems to be better then xBase++ implementation. Sharing only public with existing xBase++ code emulates it quite well with one exception. If child thread create new PUBLIC variable then it will not be visible in parent thread if it didn't have such variable allocated when thread was created. F.e.: #include "hbthread.ch" memvar PUB1, PUB2 proc main() public PUB1 := "main:pub1" ? "parent:" ? type( "PUB1" ), iif( type( "PUB1" ) != "U", PUB1, "" ) ? type( "PUB2" ), iif( type( "PUB2" ) != "U", PUB2, "" ) hb_threadJoin( hb_threadStart( HB_THREAD_INHERIT_PUBLIC, @thFunc() ) ) ? "parent:" ? type( "PUB1" ), iif( type( "PUB1" ) != "U", PUB1, "" ) ? type( "PUB2" ), iif( type( "PUB2" ) != "U", PUB2, "" ) return proc thFunc() public PUB1 := "thread:pub1" public PUB2 := "thread:pub2" ? "child:" ? type( "PUB1" ), PUB1 ? type( "PUB2" ), PUB2 return This code in Harbour shows: parent: C main:pub1 U child: C thread:pub1 C thread:pub2 parent: C thread:pub1 U If I understand well xbase++ documentation then in this language it should show: parent: C main:pub1 U child: C thread:pub1 C thread:pub2 parent: C thread:pub1 C thread:pub2 BTW If someone can confirm this then it will be nice. Otherwise we may talk about sth what does not exists. In all xbase++ documentations I've seen so far the important for me things are missing and only basic behavior is described. Just like in dbRelease()/dbDetach(). What does xbase++ with relations and active locks (RLOCK()/FLOCK() when WA is released? So public variable created by child thread is also visible in all other threads even if it didn't exist when thread is created. Now I'm thinking about real application usage. I cannot touch any shared variables without protection. It means that If I want to use it in parrent thread I have to know its name. If I know it then I can simply declare it by: public before I'll start the thread just like pub1 was declared in example above. Here new INIT PUBLIC statement can be very nicely used to initialize all such PUBLIC variables automatically when program starts. Of coures if someone want to create such global to process public variables. After rethinking the problem I'm finding xbase++ behavior as limitation not a feature because now each thread can use it's own set of public variables, known only for this thread and its child threads which can be shared between them if necessary and it does not effect parent thread. If we exactly replicate the xbase++ behavior we will stronlgy reduce PUBLIC functionality to sth what can be used only by application author which knows all PUBLIC variable names and does not have to worry about name conflicts with 3-rd party code. The final result of such model has also yet another bad side effect. Each access to public variable have to be protected by MUTEX if this is not readonly var what makes some other complications. In summary I'm finding current Harbour behavior better. I can implement xBase++ like solution even quite easy though with some additional memory cost - we will have to store PUBLICs handles directly in global dynamic symbol table which is not thread local. I've just check it. Anyhow it will not be possible to keep current optional memvar separation fully working. Just simply each thread if wants to see public variables have to access also common to all thread PUBLIC area and has to be able to create threads which can create in this area effecting all other threads even if user needs full separation. Additionally it will force using hidden for user mutex synchronization used each time global public area is accessed/assign to avoid internal structure corruption what will reduce the performance. In real applications it's very minor problem and here I do not see good reason reduce functionality, security and speed and only to replicate exact xbase++ behavior. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-09-24 20:30 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Thu, 25 Sep 2008, Maurilio Longo wrote: Hi Maurilio, > latest code, OS/2 GCC, HB_FM_STATISTICS_OFF, PIV HT 3.6GHz, SMP Kernel. > ST > > total application time: 52.85 > total real time: 52.85 > MT > > total application time: 70.91 > total real time: 70.92 Thank you for the tests. You have a little bit bigger difference then David. It's ~34%. But I cannot say exactly why. It's possible that some memory operation have different cost in MT and ST code due to different startup memory consumption by MT and ST HVMs. Anyhow it's in acceptable range. Best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-09-24 20:30 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Przemyslaw Czerpak wrote: > > Thank you for the tests. You have a little bit bigger difference then > David. It's ~34%. But I cannot say exactly why. It's possible that > some memory operation have different cost in MT and ST code due to > different startup memory consumption by MT and ST HVMs. Anyhow it's > in acceptable range. > Yes, probably differences between SMP and UNI kernels, or size of on chip cache. Anyway, I think that in real code you don't notice such a difference. Best regards. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-09-24 20:30 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Thu, 25 Sep 2008, Maurilio Longo wrote: Hi Maurilio, > Yes, probably differences between SMP and UNI kernels, or size of on chip > cache. > Anyway, I think that in real code you don't notice such a difference. Yes of course. This test measures only HVM performance on pure PCODE evaluation. In real code lot of expensive C functions is used, f.e. for database access so the difference is much smaller or even not visible at all. BTW what are xHarbour results on the same hardware in OS2? best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
Hi Przemek,
tests: 914, 917-920, 923-925, 959, 962-965, 968-970, 987-990.
Actually the new MinGW results are the right ones, but the
expected results seem to be screwed up, showing 705032704 instead of
50. Quite strange. ]
Can you send the exact hbtest output?
Pls find them attached (for both 1.0.1 and 1.1.0).
Brgds,
Viktor
Harbour Regression Test Suite
Copyright (c) 1999-2008, http://www.harbour-project.org/
---
Version: Harbour 1.1.0dev (Rev. 9502)
Compiler: MinGW GNU C 4.1.2 (32 bit)
OS: Windows XP 5.1.2600 Service Pack 3
Date, Time: 2008.09.25 12:20:53
Output: (stdout)
Shortcut opt.: ON
Switches:
===
R No. LineTestCall() -> Result
|
Expected
---
! 596 MAIN_HVMA(0)saArray[ 1000 ]
Result: "E BASE 1132 Bound error array access A:2:A:{.[1].};N:1000 "
Expected: "E BASE 1132 Bound error array access "
! 597 MAIN_HVMA(0)saArray[ 1000 ] := 1
Result: "E BASE 1133 Bound error array assign A:1:N:1000 "
Expected: "E BASE 1133 Bound error array assign "
! 726 MAIN_HVMA(0)RTSTR( 0500 )
Result: " 16 500"
Expected: " 21 500"
! 727 MAIN_HVMA(0)RTSTR( 0500 )
Result: " 16 500"
Expected: " 17 500"
! 914 MAIN_MATH(0)Round(50, 0)
Result: 50
Expected: 705032704
! 917 MAIN_MATH(0)Round(50, -1)
Result: 50
Expected: 705032704
! 918 MAIN_MATH(0)Round(50, -2)
Result: 50
Expected: 705032704
! 919 MAIN_MATH(0)Round(50, -2)
Result: 50
Expected: 705032704
! 920 MAIN_MATH(0)Round(50.129, 0)
Result: 50
Expected: 705032704
! 923 MAIN_MATH(0)Round(50.129, -1)
Result: 50
Expected: 705032704
! 924 MAIN_MATH(0)Round(50.129, -2)
Result: 50
Expected: 705032704
! 925 MAIN_MATH(0)Round(50.129, -2)
Result: 50
Expected: 705032704
! 959 MAIN_MATH(0)Round(-50, 0)
Result: -50
Expected: -705032704
! 962 MAIN_MATH(0)Round(-50, -1)
Result: -50
Expected: -705032704
! 963 MAIN_MATH(0)Round(-50, -2)
Result: -50
Expected: -705032704
! 964 MAIN_MATH(0)Round(-50, -2)
Result: -50
Expected: -705032704
! 965 MAIN_MATH(0)Round(-50.129, 0)
Result: -50
Expected: -705032704
! 968 MAIN_MATH(0)Round(-50.129, -1)
Result: -50
Expected: -705032704
! 969 MAIN_MATH(0)Round(-50.129, -2)
Result: -50
Expected: -705032704
! 970 MAIN_MATH(0)Round(-50.129, -2)
Result: -50
Expected: -705032704
! 987 MAIN_MATH(0)Int(50.90)
Result: 50
Expected: 705032704
! 988 MAIN_MATH(0)Int(-50.90)
Result: -50
Expected: -705032704
! 989 MAIN_MATH(0)Int(50)
Result: 50
Expected: 705032704
! 990 MAIN_MATH(0)Int(-50)
Result: -50
Expected: -705032704
! 1071 MAIN_MATH(0)Str(1234567890 * 1234567890 )
Result: " 1524157875019052100"
Expected: " 1524157875019052000"
! 1466 MAIN_STR(0) AllTrim( NIL )
Result: "E BASE 2022 Argument error ALLTRIM A:1:U:NIL F:S"
Expected: "E BASE 2022 Argument error ALLTRIM F:S"
! 1467 MAIN_STR(0) AllTrim( 100 )
Result: "E BASE 2022 Argument error ALLTRIM A:1:N:100 F:S"
Expected: "E BASE 2022 Argument error ALLTRIM F:S"
! 1539 MAIN_STR(0) StrTran( NIL )
Result: "E BASE 1126 Argument error STRTRAN A:1:U:NIL F:S"
Expected: "E BASE 1126 Argument error STRTRAN F:S"
! 1540 MAIN_STR(0) StrTran( 100 )
Result: "E BASE 1126 Argument error STRTRAN A:1:N:100 F:S"
Expected: "E BASE 1126 Argument error STRTRAN F:
Re: [Harbour] mingw results and Windows compiler roundup
On Thu, 25 Sep 2008, Przemyslaw Czerpak wrote:
Hi All,
> The cost of TLS access is strictly compiler/OS dependent. I've
> just make interesting experiment to compare the code of using
> stack pointer to dynamically allocated stack instead of statick
> stack address in ST programs.
> I made very simple modificatrion. In hbstack.c for ST mode I changed:
> extern HB_STACK hb_stack;
> to:
> extern PHB_STACK hb_stack_ptr;
> # define hb_stack ( * hb_stack_ptr )
> and in estack.c:
># if defined( HB_STACK_MACROS )
> HB_STACK hb_stack;
># else
> static HB_STACK hb_stack;
># endif
> to:
> HB_STACK _hb_stack_;
> PHB_STACK hb_stack_ptr = &_hb_stack_;
An now I compared BCC-5.5 and GCC-4.3.1 assembler code generated for
such modified HVM and this simple code:
void func( void )
{
hb_stackPush();
hb_stackPop();
}
BCC with -4 -5 -6 -O2 gives:
;
; void func( void )
; {
; hb_stackPush();
;
@3:
mov eax,dword ptr [_hb_stack_ptr]
add dword ptr [eax+4],4
mov edx,dword ptr [eax+4]
mov ecx,dword ptr [_hb_stack_ptr]
cmp edx,dword ptr [ecx+8]
jne short @4
call _hb_stackIncrease
;
; hb_stackPop();
;
@4:
mov eax,dword ptr [_hb_stack_ptr]
sub dword ptr [eax+4],4
mov edx,dword ptr [_hb_stack_ptr]
mov ecx,dword ptr [edx+4]
mov eax,dword ptr [ecx]
test dword ptr [eax],46085
jeshort @5
push eax
call _hb_itemClear
pop ecx
;
; }
;
@5:
@6:
ret
Please note that _hb_stack_ptr is accessed always 4 times.
In my GCC final code looks for -O3 is:
func:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
movlhb_stack_ptr, %ecx
movl4(%ecx), %eax
addl$4, %eax
cmpl8(%ecx), %eax
movl%eax, 4(%ecx)
je .L6
.L2:
movl4(%ecx), %edx
leal-4(%edx), %eax
movl%eax, 4(%ecx)
movl-4(%edx), %eax
testw $-19451, (%eax)
jne .L7
leave
ret
.L7:
movl%eax, (%esp)
callhb_itemClear
leave
ret
.L6:
callhb_stackIncrease
movlhb_stack_ptr, %ecx
jmp .L2
It access hb_stack_ptr only _ONCE_ during normal code execution.
The second hb_stack_ptr is used when external function like
hb_stackIncrease() have to be called (in practice never or few
times in whole application live).
And this explains the speed difference. Which such optimization
the overhead in my builds is minimal when TLS native variables
are used. GCC was always optimized to reduce memory access when
BCC seems to be hardcoded for x86 machines where the cost of memory
operation was relatively small in the past and now data CPU caches
reduce the overhead but it's still not friendly code for CPU
optimization logic.
It also shows why TLS cost so much in BCC. Four calls instead
of one in my GCC in such simple example.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-09-24 20:30 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Ok, here they are, same hardware, xharbour at $Id: ChangeLog,v 1.6182 2008/08/01 09:41:14 marchuet Exp $ MT total application time: 214.79 total real time:214.79 ST total application time: 95.18 total real time: 95.18 I attach full results. Best regards. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. mt.log Description: application/log st.log Description: application/log ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
On Thu, 25 Sep 2008, Szak�ts Viktor wrote: Hi Viktor, >>> tests: 914, 917-920, 923-925, 959, 962-965, 968-970, 987-990. >>> Actually the new MinGW results are the right ones, but the >>> expected results seem to be screwed up, showing 705032704 instead of >>> 50. Quite strange. ] >> Can you send the exact hbtest output? ! 914 MAIN_MATH(0)Round(50, 0) Result: 50 Expected: 705032704 This is very serious problem. Just try: proc main() ? 50 return It means that during compilation 50 in source code is stripped to 32bits. Please carefully check your build settings. I cannot replicate it in any of my C compilers and I rether do not expect that it will be wrong. It's my very old code perfectly working for years in Harbour and xHarbour. For me it looks like sth seriously wrong with LONGLONG numbers in C compiler or side effects of some experiments with macros or definitions we are using, f.e. HB_LONG type mapped to LONG without updating corresponding macros or HB_LONG_LONG_OFF used to compile only part of Harbour code, f.e. only compiler or only HVM/RTL. Or some C different compiler switches use to compile only part of Harbour code which may interact with size or alignment of data structures or ABI. Please once again carefully check you environment and try to replicate these results with _FULL_ clean build. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
On Thu, Sep 25, 2008 at 7:22 PM, Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote: > This is very serious problem. > Just try: > proc main() > ? 50 > return I don't know if it helps but I've just tried with current official mingw 3.4.5: $ gcc -v Reading specs from c:/mingw/bin/../lib/gcc/mingw32/3.4.5/specs Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.5 (mingw special) and I got the right result. Also hbtest.exe behaves correctly. best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-09-24 20:30 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Thu, 25 Sep 2008, Maurilio Longo wrote: Hi Maurilio, > Ok, here they are, > same hardware, xharbour at $Id: ChangeLog,v 1.6182 2008/08/01 09:41:14 > marchuet Exp $ > MT > total application time: 214.79 > ST > total application time: 95.18 I expected worse results then Harbour ones but I didn't expect such big difference and such big MT overhead. xHarbour does not even use protection for complex variable reference counters in OS2 builds - Walter implemented them only for MS-Windows. In my Linux box the difference is smaller though I'm using a little bit modified xHarbour version with working native TLS support. I'll made tests with current clean CVS. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re[Harbour] quest to share MT knowledge on Xbase++ NG
Today I have posted this message on Xbase++ NG: Hello Everybody Harbour developers are concentrating on Multi-Threading at the moment and have implemented the fairly advanced, optimized, and stable modal. As Xbase++ is the pioneer and is the only working MT modal in xbase world, development team has unanimously agreed to follow XBase++ MT modal in Harbour too. Because this is a design-time phase of MT implemention in Harbour, development team needs the expertise of Xbase++ community to share their experiences in any way related to MT applications. For example, it will be interesting to have a knowledgebase about features and shortcomings of Xbase++ MT modal. I, personally and on bahalf of the Clipper community, request you to participate in the discussion going on at http://www.nabble.com/A-few-questions-about-MT-to19555409.html . You never know a small comment of yours may change the MT concept. Hope to see your posts there. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/A-few-questions-about-MT-tp19555409p19675252.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
Hi Przemek, After some experimenting it looks like -gc3 is the culprit. This can be easily seen even by using harbour.exe from the official MinGW binary package. You short sample program, compiled with -gc3 will produce this line: --- hb_xvmPushLongLong( HB_LL( 705032704 ) ); --- Brgds, Viktor On 2008.09.25., at 19:22, Przemyslaw Czerpak wrote: On Thu, 25 Sep 2008, Szakáts Viktor wrote: Hi Viktor, tests: 914, 917-920, 923-925, 959, 962-965, 968-970, 987-990. Actually the new MinGW results are the right ones, but the expected results seem to be screwed up, showing 705032704 instead of 50. Quite strange. ] Can you send the exact hbtest output? ! 914 MAIN_MATH(0)Round(50, 0) Result: 50 Expected: 705032704 This is very serious problem. Just try: proc main() ? 50 return It means that during compilation 50 in source code is stripped to 32bits. Please carefully check your build settings. I cannot replicate it in any of my C compilers and I rether do not expect that it will be wrong. It's my very old code perfectly working for years in Harbour and xHarbour. For me it looks like sth seriously wrong with LONGLONG numbers in C compiler or side effects of some experiments with macros or definitions we are using, f.e. HB_LONG type mapped to LONG without updating corresponding macros or HB_LONG_LONG_OFF used to compile only part of Harbour code, f.e. only compiler or only HVM/RTL. Or some C different compiler switches use to compile only part of Harbour code which may interact with size or alignment of data structures or ABI. Please once again carefully check you environment and try to replicate these results with _FULL_ clean build. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
On Thu, 25 Sep 2008, Przemyslaw Czerpak wrote: > In my GCC final code looks for -O3 is: > func: > pushl %ebp > movl%esp, %ebp > subl$8, %esp > movlhb_stack_ptr, %ecx > movl4(%ecx), %eax > addl$4, %eax > cmpl8(%ecx), %eax > movl%eax, 4(%ecx) > je .L6 > .L2: > movl4(%ecx), %edx > leal-4(%edx), %eax > movl%eax, 4(%ecx) > movl-4(%edx), %eax > testw $-19451, (%eax) > jne .L7 > leave > ret > .L7: > movl%eax, (%esp) > callhb_itemClear > leave > ret > .L6: > callhb_stackIncrease > movlhb_stack_ptr, %ecx > jmp .L2 > > It access hb_stack_ptr only _ONCE_ during normal code execution. And next hint. I've just tried the same code but in MT mode with real native TLS access. GCC gives: func2: pushl %ebp movl%esp, %ebp subl$24, %esp movl%ebx, -8(%ebp) movl[EMAIL PROTECTED], %ebx movl%esi, -4(%ebp) movl%gs:0, %esi movl(%esi,%ebx), %edx movl(%edx), %eax addl$4, %eax cmpl4(%edx), %eax movl%eax, (%edx) je .L6 .L2: movl(%esi,%ebx), %eax movl(%eax), %ecx leal-4(%ecx), %edx movl%edx, (%eax) movl-4(%ecx), %eax testw $-19451, (%eax) je .L4 movl%eax, (%esp) callhb_itemClear .L4: movl-8(%ebp), %ebx movl-4(%ebp), %esi movl%ebp, %esp popl%ebp ret .L6: callhb_stackIncrease jmp .L2 It stores TLS pointer inside ESI[EBX] registers and then simply reuses it so even in very complicated functions it access TLS only once. It means that using HB_STACK_TLS_PRELOAD reduces only indirect addressing overhead and ESI register saveing/restoring: func2: pushl %ebp movl%gs:0, %eax movl%esp, %ebp pushl %ebx subl$4, %esp movl[EMAIL PROTECTED], %edx movl(%eax,%edx), %ebx movl(%ebx), %edx addl$4, %edx cmpl4(%ebx), %edx movl%edx, (%ebx) je .L6 .L2: leal-4(%edx), %eax movl%eax, (%ebx) movl-4(%edx), %eax testw $-19451, (%eax) je .L4 movl%eax, (%esp) callhb_itemClear .L4: addl$4, %esp popl%ebx popl%ebp ret .L6: callhb_stackIncrease movl(%ebx), %edx jmp .L2 Now it's clear why the results are such different. Each compiler which will not make such optimization will give noticeable slower code for MT mode. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
On Thu, 25 Sep 2008, Szak�ts Viktor wrote:
Hi Viktor,
> After some experimenting it looks like -gc3 is the culprit.
I expected that it may be related to -gc3 switch and before
I wrote this message rebuild Harbour with -gc3 using Linux GCC
and cross MingGW. Everything works as expected.
> This can be easily seen even by using harbour.exe from the
> official MinGW binary package.
> You short sample program, compiled with -gc3 will produce
> this line:
> ---
> hb_xvmPushLongLong( HB_LL( 705032704 ) );
> ---
But for me it's:
hb_xvmPushLongLong( HB_LL( 50 ) );
Can you check in you MinGW the folowing code:
#include
int main( void )
{
printf( "TEST NUMER = [%lld]\n", 50LL );
return 0;
}
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
Hi Przemek,
But for me it's:
hb_xvmPushLongLong( HB_LL( 50 ) );
Can you check in you MinGW the folowing code:
#include
int main( void )
{
printf( "TEST NUMER = [%lld]\n", 50LL );
return 0;
}
Gives me:
TEST NUMBER = [705032704]
In MinGW 3.4.5 (official - tested in two different machines),
4.1.2 (official), 4.3.2 (unofficial).
gcc -v outputs below:
---
Reading specs from C:/devl/MinGW-345/bin/../lib/gcc/mingw32/3.4.5/specs
Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --with-
gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --
enable-threads --disable-nls --enable-languages=c,c+
+,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-
sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --
enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --
enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw-vista special r3)
---
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../src/configure --prefix=c:/temp/gcc/dest --enable-
languages=c,c++ --disable-shared --enable-threads=win32 --disable-
win32-registry --disable-checking --disable-nls --enable-sjlj-
exceptions --disable-libstdcxx-pch
Thread model: win32
gcc version 4.1.2
---
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.3.2/configure --prefix=/mingw --
build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ --with-
bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls --
disable-win32-registry --enable-libgomp --disable-werror --enable-
threads --disable-symvers --enable-cxx-flags='-fno-function-sections -
fno-data-sections' --enable-fully-dynamic-string --enable-version-
specific-runtime-libs --enable-sjlj-exceptions --with-
pkgversion='4.3.2-tdm-1 for MinGW'
Thread model: win32
gcc version 4.3.2 (4.3.2-tdm-1 for MinGW)
---
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
Same code copied to OSX (Intel), compiled with default gcc 4.0.1
gives the right result:
---
TEST NUMBER = [50]
---
Brgds,
Viktor
On 2008.09.25., at 20:58, Szakáts Viktor wrote:
Hi Przemek,
But for me it's:
hb_xvmPushLongLong( HB_LL( 50 ) );
Can you check in you MinGW the folowing code:
#include
int main( void )
{
printf( "TEST NUMER = [%lld]\n", 50LL );
return 0;
}
Gives me:
TEST NUMBER = [705032704]
In MinGW 3.4.5 (official - tested in two different machines),
4.1.2 (official), 4.3.2 (unofficial).
gcc -v outputs below:
---
Reading specs from C:/devl/MinGW-345/bin/../lib/gcc/mingw32/3.4.5/
specs
Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --with-
gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw
--enable-threads --disable-nls --enable-languages=c,c+
+,f77,ada,objc,java --disable-win32-registry --disable-shared --
enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-
x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw-vista special r3)
---
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../src/configure --prefix=c:/temp/gcc/dest --enable-
languages=c,c++ --disable-shared --enable-threads=win32 --disable-
win32-registry --disable-checking --disable-nls --enable-sjlj-
exceptions --disable-libstdcxx-pch
Thread model: win32
gcc version 4.1.2
---
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.3.2/configure --prefix=/mingw --
build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ --
with-bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls
--disable-win32-registry --enable-libgomp --disable-werror --enable-
threads --disable-symvers --enable-cxx-flags='-fno-function-sections
-fno-data-sections' --enable-fully-dynamic-string --enable-version-
specific-runtime-libs --enable-sjlj-exceptions --with-
pkgversion='4.3.2-tdm-1 for MinGW'
Thread model: win32
gcc version 4.3.2 (4.3.2-tdm-1 for MinGW)
---
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
Hi Przemek,
I've found some pages listing %lld as one the significant
incompatibilities of MinGW compared to Linux GCC.
In MinGW the equivalent formatting seems to be:
"%I64d" which is also claimed to be the Microsoft C compatible syntax.
Testing with %I64d shows correct results in 3.4.5 and 4.3.2.
Brgds,
Viktor
On 2008.09.25., at 21:38, Szakáts Viktor wrote:
Same code copied to OSX (Intel), compiled with default gcc 4.0.1
gives the right result:
---
TEST NUMBER = [50]
---
Brgds,
Viktor
On 2008.09.25., at 20:58, Szakáts Viktor wrote:
Hi Przemek,
But for me it's:
hb_xvmPushLongLong( HB_LL( 50 ) );
Can you check in you MinGW the folowing code:
#include
int main( void )
{
printf( "TEST NUMER = [%lld]\n", 50LL );
return 0;
}
Gives me:
TEST NUMBER = [705032704]
In MinGW 3.4.5 (official - tested in two different machines),
4.1.2 (official), 4.3.2 (unofficial).
gcc -v outputs below:
---
Reading specs from C:/devl/MinGW-345/bin/../lib/gcc/mingw32/3.4.5/
specs
Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --
with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/
mingw --enable-threads --disable-nls --enable-languages=c,c+
+,f77,ada,objc,java --disable-win32-registry --disable-shared --
enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-
x --enable-java-gc=boehm --disable-libgcj-debug --enable-
interpreter --enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw-vista special r3)
---
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../src/configure --prefix=c:/temp/gcc/dest --
enable-languages=c,c++ --disable-shared --enable-threads=win32 --
disable-win32-registry --disable-checking --disable-nls --enable-
sjlj-exceptions --disable-libstdcxx-pch
Thread model: win32
gcc version 4.1.2
---
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.3.2/configure --prefix=/mingw --
build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ --
with-bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls
--disable-win32-registry --enable-libgomp --disable-werror --enable-
threads --disable-symvers --enable-cxx-flags='-fno-function-
sections -fno-data-sections' --enable-fully-dynamic-string --enable-
version-specific-runtime-libs --enable-sjlj-exceptions --with-
pkgversion='4.3.2-tdm-1 for MinGW'
Thread model: win32
gcc version 4.3.2 (4.3.2-tdm-1 for MinGW)
---
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-09-25 21:50 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-09-25 21:50 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * include/hbdefs.h ! Fixed 64-bit printf() formatting strings to be compatible with MinGW. MinGW seems to follow the Microsoft way instead of being compatible with other GCC dialects. This fixes some pcode/c code (-gc3) generation problems for long long literals, and hbfbird/FBGETDATA() potential problems, when MinGW 3.x/4.x compilers were used. [TOMERGE 1.0] ; TOFIX: Some sqlite3.c code may also be affected, since "%llX" and "%lld"s are hard-coded into the source. -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
On Thu, Sep 25, 2008 at 9:44 PM, Szakáts Viktor <[EMAIL PROTECTED]> wrote: > I've found some pages listing %lld as one the significant > incompatibilities of MinGW compared to Linux GCC. > > In MinGW the equivalent formatting seems to be: > "%I64d" which is also claimed to be the Microsoft C compatible syntax. > > Testing with %I64d shows correct results in 3.4.5 and 4.3.2. I've just found that adding -ansi "corrects" %lld under 3.4.5. best regards, Lorenzo ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
On Thu, 25 Sep 2008, Szak�ts Viktor wrote: Hi Viktor, > I've found some pages listing %lld as one the significant > incompatibilities of MinGW compared to Linux GCC. > In MinGW the equivalent formatting seems to be: > "%I64d" which is also claimed to be the Microsoft C compatible syntax. > Testing with %I64d shows correct results in 3.4.5 and 4.3.2. So I'll add MinGW to the list of other Windows compilers which uses I64 in hbdefs.h. It will resolve the problem. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
Szakáts Viktor wrote:
>
>> Gives me:
>> TEST NUMBER = [705032704]
>
#include
#include
int main( void )
{
printf( "TEST NUMER = [%lld]\n",50LL );
printf( "TEST NUMER = [%I64u]\n", 50LL );
return 0;
}
http://www.nabble.com/long-long-int-printf-query-td16372489.html#a16372489
http://www.nabble.com/long-long-int-printf-query-td16372489.html#a16372489
--
View this message in context:
http://www.nabble.com/mingw-results-and-Windows-compiler-roundup-tp19640310p19677563.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
I've already did it, but it's the best if you take a second look (I can make a mistake virtually anywhere :) Question, what to do with sqlite3.c. Brgds, Viktor On 2008.09.25., at 22:12, Przemyslaw Czerpak wrote: On Thu, 25 Sep 2008, Szak�ts Viktor wrote: Hi Viktor, I've found some pages listing %lld as one the significant incompatibilities of MinGW compared to Linux GCC. In MinGW the equivalent formatting seems to be: "%I64d" which is also claimed to be the Microsoft C compatible syntax. Testing with %I64d shows correct results in 3.4.5 and 4.3.2. So I'll add MinGW to the list of other Windows compilers which uses I64 in hbdefs.h. It will resolve the problem. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
Przemek, I do not know details for MinGW TLS but it's possible that it will be imporved yet in the future, f.e. now thay can use simple function call like in BCC. Anyhow in current SVN code the cost of TLS is quite efficient hidden by HB_STACK_PRELOAD. Just try to remove: #define HB_STACK_PRELOAD fro the beginning of estack.c and hvm.c and rebuild Harbour without HB_USE_TLS. Then compare the results. If they will be the same then probably current MinGW version simply calls TlsGetValue() for native TLS access so it the same as calling this function by us. I've now created a new local production build (which fixed -gc3 / hbtest) with above changes, and results went up to 96.67 / 97.39 compared to unmodified build value 64.38 / 64.81. Both with MinGW 4.3.2. I hope this helps. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
On Thu, 25 Sep 2008, Szak�ts Viktor wrote: > I've already did it, but it's the best if you take a second look > (I can make a mistake virtually anywhere :) You made exactly what I did with the byte precision ;-) so after svn update I do not have any conflicts and hbdefs.h is not marked as modified in my code. I have to say that people working on MinGW port are really funny sumtimes. MinGW supports LL suffix for long long int numbers which is even strictly necessary but does not support 'll' in printf() format and use MS extension. Who is defining it :-) BTW I've just found that in my MinGW builds PRG_USR was overwritten by other settings and this build was created with default -gc switch when I was making testing it. In summary it will be good to implement our own *printf() formatting somewhere. It's the most expensive function we are using from C RTL and quite often written in two versions for MT and ST mode. The ST one simply uses static variables. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
Hi Przemek, On Thu, 25 Sep 2008, Szak�ts Viktor wrote: I've already did it, but it's the best if you take a second look (I can make a mistake virtually anywhere :) You made exactly what I did with the byte precision ;-) so after svn update I do not have any conflicts and hbdefs.h is not marked as modified in my code. I have to say that people working on MinGW port are really funny sumtimes. MinGW supports LL suffix for long long int numbers which is even strictly necessary but does not support 'll' in printf() format and use MS extension. Who is defining it :-) I have no idea, anyhow lucky we have standards in the computing field :) BTW I've just found that in my MinGW builds PRG_USR was overwritten by other settings and this build was created with default -gc switch when I was making testing it. In summary it will be good to implement our own *printf() formatting somewhere. It's the most expensive function we are using from C RTL and quite often written in two versions for MT and ST mode. The ST one simply uses static variables. Seems like a good idea. Considering the few CRTL stuff we use, maybe we could just get rid of them all. At least as far as core is concerned. [ Clipper did it, too. ] BTW, I've just looked into the build results and there are 4 new warnings after the hbdefs.h change :( ../../genc.c:1585: warning: format '%I64i' expects type 'int', but argument 3 has type 'long long int' ../../gencc.c:1239: warning: format '%I64i' expects type 'int', but argument 3 has type 'long long int' ../../estack.c:1019: warning: format '%I64i' expects type 'int', but argument 2 has type 'HB_LONG' ../../hbsqlit3.c:1136: warning: format '%I64d' expects type 'int', but argument 4 has type 'sqlite3_uint64' Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw results and Windows compiler roundup
Szakáts Viktor wrote:
>
>
> Question, what to do with sqlite3.c.
>
> Brgds,
> Viktor
>
>
I thinks authors of sqlite know this bug
#if defined(SQLITE_TEST) || defined(SQLITE_DEBUG) ||
defined(SQLITE_MEMDEBUG)
/*
** A version of printf() that understands %lld. Used for debugging.
** The printf() built into some versions of windows does not understand %lld
** and segfaults if you give it a long long int.
*/
SQLITE_PRIVATE void sqlite3DebugPrintf(const char *zFormat, ...){
also all "fprintf" is guarded by SQLITE_DEBUG.
In first looks all it safe.
Regards,
Petr
--
View this message in context:
http://www.nabble.com/mingw-results-and-Windows-compiler-roundup-tp19640310p19678278.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: 2008-09-24 20:30 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
[Maurilio]
latest code, OS/2 GCC, HB_FM_STATISTICS_OFF, PIV HT 3.6GHz, SMP Kernel.
ST
total application time: 52.85
total real time: 52.85
MT
total application time: 70.91
total real time: 70.92
[Maurilio]
Ok, here they are,
same hardware, xharbour at $Id: ChangeLog,v 1.6182 2008/08/01 09:41:14
marchuet Exp $
MT
total application time: 214.79
ST
total application time: 95.18
[Przemek]
I expected worse results then Harbour ones but I didn't expect such
big difference and such big MT overhead. xHarbour does not even use
protection for complex variable reference counters in OS2 builds -
Walter implemented them only for MS-Windows.
In my Linux box the difference is smaller though I'm using a little
bit modified xHarbour version with working native TLS support. I'll
made tests with current clean CVS.
I see many surprises:
a) PIV HT 3.6GHz, SMP Kernel.
My hardware for OS/2 tests are AMD Athlon 2200+ 2.0 Ghz 1 Gb RAM
This Athlon never are ahead of an PIV 2.2 GHz, my "old" PIV 3.3 GHz HT
was allways near double speed than Athlon in any test
So something is wrong: results for PIV HT 3.6 Ghz should be better than
Athlon 2200+ at least in half of time
Or your machine is heavily loaded, or low RAM or something else, but
must be better
b) A very big difference between Harbour and xHarbour in both ST and MT
c) A very big difference between ST and MT in xHarbour
As I have xHarbour MT under OS/2 (yes, Maurilio told me how to build it)
I made same tests. xHarbour around 14 August 2008
speedtst.prg
Harbour
===
ST
total application time: 47.13
total real time: 47.14
MT
total application time: 51.98
total real time: 51.98
xHarbour
ST
total application time: 71.52
total real time: 71.52
MT
total application time: 119.68
total real time:119.69
Again, results should be greater than those of Maurilio hardware
Complete results for xHarbour are below
David Macias
-
xHarbour ST
Startup loop to increase CPU clock...
09/25/08 15:05:22 xHarbour build 1.1.0 Intl. (SimpLex) (Rev. 6192), OS/2
4.50
ARR_LEN = 16
N_LOOPS =100
empty loops overhead = 0.23
CPU usage -> secondsCPU()
c:=L_C -> 0.15
n:=L_N -> 0.13
d:=L_D -> 0.13
c:=M_C -> 0.16
n:=M_N -> 0.14
d:=M_D -> 0.14
(sh) c:=F_C ->0.64
(sh) n:=F_N ->0.42
(sh) d:=F_D ->0.29
(ex) c:=F_C ->0.66
(ex) n:=F_N ->0.35
(ex) d:=F_D ->0.28
n:=o:GenCode -> 0.57
n:=o[8] ->0.29
round(i/1000,2) ->1.00
str(i/1000) ->2.08
val(a3[i%ARR_LEN+1]) -> 1.11
dtos(j+i%1-5000) -> 1.16
eval({||i%ARR_LEN}) ->0.82
eval({|x|x%ARR_LEN},i) -> 0.88
eval({|x|f1(x)},i) -> 1.44
&('f1('+str(i)+')') -> 10.85
eval([&('{|x|f1(x)}')]) ->1.43
j := valtype(a)+valtype(i) -> 1.76
j := str(i%100,2) $ a2[i%ARR_LEN+1] ->2.41
j := val(a2[i%ARR_LEN+1]) -> 1.30
j := a2[i%ARR_LEN+1] == s -> 0.71
j := a2[i%ARR_LEN+1] = s -> 0.71
j := a2[i%ARR_LEN+1] >= s -> 0.70
j := a2[i%ARR_LEN+1] < s -> 0.69
aadd(aa,{i,j,s,a,a2,t,bc}) -> 2.94
f0() -> 0.67
f1(i) -> 0.80
f2(c[8]) -> 0.76
f2(c[4]) -> 0.74
f2(@c[4]) -> 0.71
f2(c[4]); c2:=c ->0.89
f2(@c[4]); c2:=c ->
Re: [Harbour] mingw results and Windows compiler roundup
On Thu, 25 Sep 2008, Szak�ts Viktor wrote: Hi Viktor, > Seems like a good idea. Considering the few CRTL stuff we use, > maybe we could just get rid of them all. At least as far as core is > concerned. [ Clipper did it, too. ] Some function like memcpy() or memmove() are very often inlined and highly optimized so not for all of them I will want to make such replacement. But things like *printf() and FILE based function can be eliminated. > BTW, I've just looked into the build results and there are 4 new > warnings after the hbdefs.h change :( > ../../genc.c:1585: warning: format '%I64i' expects type 'int', but argument > 3 has type 'long long int' > ../../gencc.c:1239: warning: format '%I64i' expects type 'int', but > argument 3 has type 'long long int' > ../../estack.c:1019: warning: format '%I64i' expects type 'int', but > argument 2 has type 'HB_LONG' > ../../hbsqlit3.c:1136: warning: format '%I64d' expects type 'int', but > argument 4 has type 'sqlite3_uint64' In all four places the code is correct and passed value is 64bit signed integer. Just simply MinGW developers added support for I64 in *printf() but they forgot to update expected type validation which should mot be 'int' but 'long long int' for such formatting and MinGW reports wrong warnings. It's a bug in MinGW. I only hope it does not effect generated code. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re[Harbour] quest to share MT knowledge on Xbase++ NG
Hi And I got this reply: Pritpal, why should I as a Xbase++ developer help a competitor to advance its product??? And why do you ask for our help in the Xbase++ generic newsgroup? In my eyes this is trolling. This has nothing to do with Xbase++. Maybe you should visit the thread started by Massimo in the soapbox newsgroup. This will help you to understand how Xbase++ developers think about this. Maybe in future times I and others should start some interesting threads in the Harbour groups about the great new enhancements within Xbase++? Lets see how other harbour developers react to this! Jan -- View this message in context: http://www.nabble.com/A-few-questions-about-MT-tp19555409p19678591.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re[Harbour] quest to share MT knowledge on Xbase++ NG
I can understand the feelings of Jan to be honest. I have no idea what kind of newsgroup is where you've posted this message, but if XBase++ developers frequent it, this can easily be taken as offense and the result is kinda predictable. Set aside the above, I think we have enough expertise and available information (maybe even working copies of XBase++ for testing) to be able to polish the MT support to have the best available solution, be it fully or partially XBase++ compatible. So I think it's up to us local XBase++ users to make anything like the above happen. [ I'm no XBase++ user BTW. ] So far though, no test results were posted on Przemek's request, which makes it look like we don't even care that much. Brgds, Viktor On 2008.09.25., at 23:22, Pritpal Bedi wrote: Hi And I got this reply: Pritpal, why should I as a Xbase++ developer help a competitor to advance its product??? And why do you ask for our help in the Xbase++ generic newsgroup? In my eyes this is trolling. This has nothing to do with Xbase++. Maybe you should visit the thread started by Massimo in the soapbox newsgroup. This will help you to understand how Xbase++ developers think about this. Maybe in future times I and others should start some interesting threads in the Harbour groups about the great new enhancements within Xbase++? Lets see how other harbour developers react to this! Jan -- View this message in context: http://www.nabble.com/A-few-questions-about-MT-tp19555409p19678591.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re[Harbour] quest to share MT knowledge on Xbase++ NG
BTW folks, I'm seeing replies on nabble.com (by Angel Pais for example) to this thread, but these messages don't make it to this list (which is BTW perfectly okay to avoid spam). I see this whole nabble/gmain cross-posting a big mess, and just a way to scatter information and making the wrong impression for users. Brgds, Viktor On 2008.09.25., at 23:22, Pritpal Bedi wrote: Hi And I got this reply: Pritpal, why should I as a Xbase++ developer help a competitor to advance its product??? And why do you ask for our help in the Xbase++ generic newsgroup? In my eyes this is trolling. This has nothing to do with Xbase++. Maybe you should visit the thread started by Massimo in the soapbox newsgroup. This will help you to understand how Xbase++ developers think about this. Maybe in future times I and others should start some interesting threads in the Harbour groups about the great new enhancements within Xbase++? Lets see how other harbour developers react to this! Jan -- View this message in context: http://www.nabble.com/A-few-questions-about-MT-tp19555409p19678591.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [SPAM] Re: Re[Harbour] quest to share MT knowledge on Xbase++ NG
On Thu, 25 Sep 2008, Pritpal Bedi wrote: Hi Pritpal, > Pritpal, > why should I as a Xbase++ developer help a competitor to advance its > product??? > And why do you ask for our help in the Xbase++ generic newsgroup? In my > eyes this is trolling. This has nothing to do with Xbase++. > Maybe you should visit the thread started by Massimo in the soapbox > newsgroup. This will help you to understand how Xbase++ developers think > about this. > Maybe in future times I and others should start some interesting threads > in the Harbour groups about the great new enhancements within Xbase++? > Lets see how other harbour developers react to this! I'm not surprised with such answer. xbase++ is commercial project so it's rather expected. BTW I like that they clearly said what they think about it. Personally I like some xbase++ ideas you presented here but I'm not interested in any implementation details. Also so far I haven't seen anything what I is new for me and what I wasn't plan to implement though with different names or with some a little bit different conditions. And I do not have any knowledge about xbase++ so I do not agree that you said that we are following xbase++ model. Some of their solutions are natural and probably anyone who think about it longer will end with sth similar. F.e. I was thinking about moving workareas between threads. When you send information about dbRelease()/dbRequest() I found it as nice API for such solution and I added it quite fast. But the internal implementation is for sure different then the one in xbase++. We do not have any zero zone but simple array item which holds areas. It's the result of my original idea when I wanted to add code to move workarea into variable which can be moved between threads and then attached to thread local WA list. I decided to use xbase++ compatible .prg interface only for one reason. In the example you sent is nicely visible that it will work with only one thread two and also with some modifications with many worker threads which are waiting for jobs from other threads. It was a little bit like in LINDA and I already found it nice :-) I do not need any think more. The only one think which can be usable is making some tests of real xbase++ behavior if you expect I'll create some compatible .prg level interface. F.e. what happens with relations and lock in dbRealese(). I have to take some arbitrary decisions like removing all relations (and I cannot change it because it will break WA separation) and removing all locks what I can change if you will find it as necessary for xBase++ compatibility though I do not like this idea very much. As you can read in other thread I also do not like documented xBase++ PUBLIC behavior and I'm finding current Harbour solution as better and I would like to keep it. In xbase++ documentation you sent I do not find anything about dangerous situations and possible bad side effects. Only small information that programmer should eliminate some situations (f.e. simultaneous write access) with some trivial examples. I can only guess that they do not want to write about real low level problems because it's commercial project and they do not want to lost customers informing that application may cause GPF. But I think that real xBase++ user well know what can happen in some cases and many times saw GPF. Even such small thing will be problem in serious conversation in public forum. And the final thing. All code I'm creating for [x]Harbour it based on my own ideas and low level implementations. I do not want to create even potential owner rights problems. Closer cooperation with commercial clipper compatible compiler authors may cause sth like that so I'm not interesting in it. I hope that I also clearly presented my point of view. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour announcement on XBase++ NG :(
Hi Massimo and all, Probably the intention is good, but please guys could you just think it twice before posting Harbour "advertisements" on other non-free Clipper compatible product forums? This is least to say impolite and really unnecessary from our POV, besides painting a pretty wrong image of Harbour. There are other - much better / yet probably more time-consuming - ways to contribute to this project, if you really want, and we probably all know what I'm talking about. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [SPAM] Re: Re[Harbour] quest to share MT knowledge on Xbase++ NG
On Fri, 26 Sep 2008, Szak�ts Viktor wrote: > BTW folks, I'm seeing replies on nabble.com (by Angel Pais > for example) to this thread, but these messages don't make > it to this list (which is BTW perfectly okay to avoid spam). Hi Viktor and Angel, I've just read this message and I've got answer for one thing. Many thanks. Publics are really global and the assign is done in atomic operation what is the additional necessary protection I was writing about in previous message. But to make it fully safe also access has to be done as atomic operation or they have to extensively use GC. I also found interesting information that statics are protected too. I guess it's internal VM protection only not logical protection. I can implement such protection but on some platforms it may be expensive so I'm not sure it's worth to do. I'll return to this problem in some spare time when I'll make some real speed tests. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour announcement on XBase++ NG :(
Sorry Viktor >Hi Massimo and all, My post was related with knowledge on MT issues which can be well described by Xbase++ user. Also I have learned that it is not good to post any such messages on their NG. Probably one more message will be my last on this topic. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/Harbour-announcement-on-XBase%2B%2B-NG-%3A%28-tp19679834p19680425.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [SPAM] Re: Re[Harbour] quest to share MT knowledge on Xbase++ NG
On Fri, 26 Sep 2008, Przemyslaw Czerpak wrote:
> Publics are really global and the assign is done in atomic
> operation what is the additional necessary protection I was writing
> about in previous message. But to make it fully safe also access has
> to be done as atomic operation or they have to extensively use GC.
But I'm looking at the code example and for me it's not MT safe or
xBase++ makes sth else what is not documented.
> I ussually carry aplication-wide info in a public array protected by a public
> logical var
>
> EJ:
>
> public aConfig := {.t.}
> public lInUse := .f.
>
> then in each thread when I want to modify the array I do (simplified example,
> it is usually encapsulated in a class):
>
> do while lInUse
> enddo
> lInUse := ! lInUse
> if lInUse // another thread may come in the interim
>aadd(aConfig,'elem')
>lInUse := ! lInUse
> endif
In this code we have:
lInUse := ! lInUse
To make this code MT safe the above line has to be one atomic
operation in xBase++. Is it true?
If not then two threads can at the same time read lInUse receive
.f. then each of them will revert its value and store in atomic
operation into lInUse.
Then both will pass successfully the test:
if lInUse // another thread may come in the interim
and will make aadd().
On single CPU machine and seldom calls two above code it may
work 99.9% of cases and will fail only when OS change active
thread context between access and assign operations in line:
lInUse := ! lInUse
But in multi CPU ones when cost of operation inside
if InUse
...
lInUse := ! lInUse
endif
is relatively high then you have big chance that two threads will
be blocked simultaneously at:
do while lInUse
enddo
then both will be unblocked and you have very big chance that they
will make next instruction well synchronized and both will access
the critical section.
The key is in:
lInUse := ! lInUse
line. This code can be MT safe _only_ if xBase++ executes this
whole line as one atomic operation.
So far I haven't found any information about such functionality.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour announcement on XBase++ NG :(
Hi Pritpal, I know, this mail was targeted to Massimo specifically. Brgds, Viktor On 2008.09.26., at 1:58, Pritpal Bedi wrote: Sorry Viktor Hi Massimo and all, My post was related with knowledge on MT issues which can be well described by Xbase++ user. Also I have learned that it is not good to post any such messages on their NG. Probably one more message will be my last on this topic. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/Harbour-announcement-on-XBase%2B%2B-NG-%3A%28-tp19679834p19680425.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] [SPAM] Re: Request to share MT knowledge on Xbase++ NG
Przemek > why should I as a Xbase++ developer help a competitor to advance its > product??? > And why do you ask for our help in the Xbase++ generic newsgroup? In my Please do not understand me wrong. I know you have implemented far superior MT design than Xbase++, I swear. My point was to gather in-production difficulties/achievements of MT modal. Having said that no more posts on Xbase++ NG. Harbour users has full faith into your capabilities as has been said many times. Do whatever you think is best for this protocol. Prg level interface is quiet simple and can be implemented in a day or two. Sorry if this has caused any inconvenience to you. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/A-few-questions-about-MT-tp19555409p19680441.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] [SPAM] Re: Request to share MT knowledge on Xbase++ NG
Hi Przemek First of all I must say you are right, this code isn't thread safe: lInUse := ! lInUse But i've also said its only a simplification. In a real program this code: 1- goes inside a sync method of a class 2- the logical var does not exit 3- the array is a var of the class 4- the class is referenced by in a Public var My intention was to show you that any manipulation of a public var must be enclosed by some kind of semaphore ( be it implemented as a sync method, mutex or logical var) Excuse me, such loose sample I gave you. Any code you want compiled and tested in xbase++ just send it to me and I'll be glad to report the results back to you. Angel -- View this message in context: http://www.nabble.com/A-few-questions-about-MT-tp19555409p19680697.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [SPAM] Re: Re[Harbour] quest to share MT knowledge on Xbase++ NG
The key is in: lInUse := ! lInUse line. This code can be MT safe _only_ if xBase++ executes this whole line as one atomic operation. So far I haven't found any information about such functionality. I see no sign this expression would be atomic. I'd think if it would be, there would exist some sort of documentation (but at list a list) of the such automatically grouped operations, otherwise it's very difficult to decide for a programmer what to expect. It's even more difficult to test. But of course, I may be wrong. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-09-26 02:42 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
2008-09-26 02:42 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/source/vm/thread.c ! fixed thread cleanup code when startthread() fails, f.e. OS refuse to create new thread. best regards Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re[Harbour] quest to share MT knowledge on Xbase++ NG
Rodd RoddGraham wrote: > > Please look again at Xbase++ NG. Jan does not represent my position and > other Xbase++ users may yet respond. > Thanks for the support. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/A-few-questions-about-MT-tp19555409p19681131.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re[Harbour] quest to share MT knowledge on Xbase++ NG
Pritpal Bedi wrote: > > And I got this reply: > > > Pritpal, > > why should I as a Xbase++ developer help a competitor to advance its > product??? > > > Please look again at Xbase++ NG. Jan does not represent my position and other Xbase++ users may yet respond. -- View this message in context: http://www.nabble.com/A-few-questions-about-MT-tp19555409p19681028.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re[Harbour] quest to share MT knowledge on Xbase++ NG
Pritpal Bedi wrote: > > Today I have posted this message on Xbase++ NG: > > For example, it will be interesting to have a knowledgebase > about features and shortcomings of Xbase++ MT modal. > > As a MT Xbase++ user, I have knowledge of its features and shortcommings. 1) Xbase++ is MT, but only reliable on single cpu core within the process. By default, the Xbase++ runtime sets single core affinity with the OS. In fact you must make an undocumented setting to allow Xbase++ to use multiple cores after which it will lock (live or dead I do not know) in a race condition. I speculate it is the fact that the developer likes to self implement the thread concurrency controls at the metal rather than using the OS facilities. The undocumented setting changes the thread synchronization algorithm used from one optimized for single core which is incompatible in a multi-core environment. To the developers credit, see item #3 for the reason why thread synchronization performance is a big issue in xBase dialects. My experience is Xbase++ performance is unacceptable when attempting multi-core processing even if the lock issue was resolved. Probably why it is not a big priority for Alaska to fix. 2) PUBLICs are global, PRIVATEs and WORKAREAs are thread local. IMO, you have flexibility in defining visibility scope as you add MT to harbour since pre-existing non-MT code does not have the concept of thread local nor does it have more than one thread. From my perspective, the xBase++ scoping is correct as PUBLICs/PRIVATEs are rarely used in a professional architecture and only necessary when they must be accessed by runtime symbolic references. WORKAREAs could go either way, but it simplifies concurrency to file locking for native file RDDs to have them thread local. Of course with DBS based RDDs (such as ADS), the session layer may impose serialization when shared across threads which leads me to conclude that the entire data layer is thread local. It is because I use ADS and the session serialization that I do not pass WORKAREAs between threads in Xbase++. Additionally, you have to make a pass of your process state settings (ie. SET commands) and decide whether they make more sense globally or thread locally. When in doubt, I lean towards SETtings being thread local since they should inherit from the thread that created them which makes them behave like global settings if set appropriately in the first thread and never changed again. If the SETting can have inter-thread side effects, it should be thread local. 3) The single core affinity referred to in item #1 above results in improved process thoroughput in Xbase++. Unlike MT at the C level, the garbage collected, shared memory system of xBase languages becomes a choke point due to excessive serialization required to guarantee integrity. Every memory variable accessed in every expression must be serialized to ensure the validity of the access. Xbase++ uses the single core optimization that is is not possible for two threads to attempt serialization in the exact same clock cycle such that certain cpu primitives are guaranteed atomic to complete without context switch. Hence, they reduce the overheads associated the traditional hardware level, multi core synchronization instructions. Memory serialization and concurrency is a well known issue for C developers, but it is exasperated by the single shared memory architecture of the xBase language. 4) While I am not an implementor of the underlying memory managers, I have contemplated how to overcome this problem in Xbase++. The best idea I have to address this problem is to create variables in thread local memory heaps that do not require thread synchronization to access. If a thread accesses a variable in another threads heap, it would trigger a move event that would relocate the variable to a shared, global heap which requires synchronization on all accesses. Of course the move event would require synchronization with the thread that owns the local heap. I believe that this would work since the vast majority of variables are not shared between threads. The GC would only need to synchronize with one thread at a time to clean the thead local heaps and hopefully the shared, global heap would be small enough that the GC disruption would be limited due to a quick run and the possibility that the application threads might not access the global heap (ie. be processing from the thread local heap) during its GC. The downside of this architecture is that process memory may fragment quickly due to multiple heaps and exhaust Win32 limits. Of course Win64 breaking the 3GB process memory limit is just around the corner. 5) Finally, the only thread synchronization feature of Xbase++ at the .PRG level is SYNC METHODs which serialize on the object instance (or class object for CLASS SYNC METHODs). This is straight forward implementation that requires nothing more than including a serialization mutex in e
Re: Re[Harbour] quest to share MT knowledge on Xbase++ NG
I have attempted to post my Xbase++ MT knowledge on the nabble.com link you provided. However it keeps saying that the post was not accepted by the mail list. As I spent some effort trying to share, can someone confirm that it is posted for all to see or what I need to do to post it. It is somewhat long, but I do not think it is a size limit. Thanks, Rodd Graham -- View this message in context: http://www.nabble.com/A-few-questions-about-MT-tp19555409p19681861.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re[Harbour] quest to share MT knowledge on Xbase++ NG
Rodd RoddGraham wrote: > > > I have attempted to post my Xbase++ MT knowledge on the nabble.com link > you provided. However it keeps saying that the post was not accepted by > the mail list. > > As I spent some effort trying to share, can someone confirm that it is > posted for all to see or what I need to do to post it. It is somewhat > long, but I do not think it is a size limit. > > Thanks, > > Rodd Graham > > It is visible on the list. For some time Nabble reports this message while the message gets delivered, I do not know why. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/A-few-questions-about-MT-tp19555409p19682085.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re[Harbour] quest to share MT knowledge on Xbase++ NG
I'll stick my nose in here with the suggestion that perhaps this is not the proper place to discuss this material. As valid as the topic might be on a neutral newsgroup, there are all sorts of possible ramifications and unintended consequences that can come of discussions here that could affect development of Harbour. There must be other venues where this discussion can be conducted, (and I'd love to follow those threads) but my vote is to stick with Harbour-specific topics in the Harbour newsgroups. As always, much appreciation for all the tremendous work, contribution and exciting results we all appreciate in the development of this compiler. Bill On Thu, 2008-09-25 at 18:27 -0700, Pritpal Bedi wrote: > Rodd > > > RoddGraham wrote: > > > > Please look again at Xbase++ NG. Jan does not represent my position and > > other Xbase++ users may yet respond. > > > > Thanks for the support. > > Regards > Pritpal Bedi > ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
