Re: [Harbour] Re: XBASE++ speedtst
On Sat, 28 Mar 2009, Angel Pais wrote: Hi, > this is the .bat file I use to compile Harbour. > All the rest is pure svn code. > compile.bat > SET PATH=C:\vsk\vc\bin;C:\vsk\bin; > SET LIB=C:\vsk\vc\lib;C:\vsk\lib; > SET INCLUDE=C:\vsk\vc\include;C:\vsk\include; > set HB_COMPILER=msvc > set HB_INSTALL_PREFIX=C:\harbour > set HB_VISUALC_VER=90 > set HB_USER_CFLAGS=-DHB_FM_STATISTICS_OFF > call make_gnu.bat clean > make_gnu_cln.txt > call make_gnu.bat install> make_gnu_log.txt Thank you very much for confirmation. Can you also check what will happen if you rebuild Harbour with: set HB_USER_CFLAGS=-DHB_FM_STATISTICS_OFF -DHB_FM_WIN_ALLOC best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[10721] trunk/harbour
Revision: 10721 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10721&view=rev Author: vszakats Date: 2009-03-29 09:09:24 + (Sun, 29 Mar 2009) Log Message: --- 2009-03-29 11:02 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * INSTALL * external/Makefile + external/libhpdf/* + external/libpng/* + Added libharu and libpng to Harbour repository. Now it's possible to use libhpdf as static lib on all platforms. This is useful because this lib isn't yet part of Linux distros. libpng is only built for win/dos/os2 platforms. It's possible to override libpng location by using HB_INC_LIBPNG envvar. * contrib/hbhpdf/Makefile + Look for libharu headers in /external dir. * external/sqlite3/Makefile - Disabled for bcc. Latest sqlite3 version breaks with this compiler: --- Error E2293 ../../sqlite3.c 29156: ) expected in function winCurrentTime Warning W8013 ../../sqlite3.c 29157: Possible use of 'timeW' before definition in function winCurrentTime Error E2379 ../../sqlite3.c 29157: Statement missing ; in function winCurrentTime Error E2379 ../../sqlite3.c 29158: Statement missing ; in function winCurrentTime Error E2379 ../../sqlite3.c 29160: Statement missing ; in function winCurrentTime Error E2293 ../../sqlite3.c 29161: ) expected in function winCurrentTime Error E2379 ../../sqlite3.c 29162: Statement missing ; in function winCurrentTime Error E2293 ../../sqlite3.c 29163: ) expected in function winCurrentTime Warning W8057 ../../sqlite3.c 29171: Parameter 'prNow' is never used in function winCurrentTime *** 7 errors in Compile *** --- bcc users can report this problem here: http://www.sqlite.org/cvstrac/tktnew + tests/bnch_win.bat - tests/bnchmark * Moved bnch_win.bat to tests. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/INSTALL trunk/harbour/contrib/hbhpdf/Makefile trunk/harbour/external/Makefile trunk/harbour/external/sqlite3/Makefile Added Paths: --- trunk/harbour/external/libhpdf/ trunk/harbour/external/libhpdf/Makefile trunk/harbour/external/libhpdf/README trunk/harbour/external/libhpdf/hpdf.h trunk/harbour/external/libhpdf/hpdf_annotation.c trunk/harbour/external/libhpdf/hpdf_annotation.h trunk/harbour/external/libhpdf/hpdf_array.c trunk/harbour/external/libhpdf/hpdf_binary.c trunk/harbour/external/libhpdf/hpdf_boolean.c trunk/harbour/external/libhpdf/hpdf_catalog.c trunk/harbour/external/libhpdf/hpdf_catalog.h trunk/harbour/external/libhpdf/hpdf_conf.h trunk/harbour/external/libhpdf/hpdf_config.h trunk/harbour/external/libhpdf/hpdf_consts.h trunk/harbour/external/libhpdf/hpdf_destination.c trunk/harbour/external/libhpdf/hpdf_destination.h trunk/harbour/external/libhpdf/hpdf_dict.c trunk/harbour/external/libhpdf/hpdf_doc.c trunk/harbour/external/libhpdf/hpdf_doc.h trunk/harbour/external/libhpdf/hpdf_doc_png.c trunk/harbour/external/libhpdf/hpdf_encoder.c trunk/harbour/external/libhpdf/hpdf_encoder.h trunk/harbour/external/libhpdf/hpdf_encoder_cns.c trunk/harbour/external/libhpdf/hpdf_encoder_cnt.c trunk/harbour/external/libhpdf/hpdf_encoder_jp.c trunk/harbour/external/libhpdf/hpdf_encoder_kr.c trunk/harbour/external/libhpdf/hpdf_encrypt.c trunk/harbour/external/libhpdf/hpdf_encrypt.h trunk/harbour/external/libhpdf/hpdf_encryptdict.c trunk/harbour/external/libhpdf/hpdf_encryptdict.h trunk/harbour/external/libhpdf/hpdf_error.c trunk/harbour/external/libhpdf/hpdf_error.h trunk/harbour/external/libhpdf/hpdf_ext_gstate.c trunk/harbour/external/libhpdf/hpdf_ext_gstate.h trunk/harbour/external/libhpdf/hpdf_font.c trunk/harbour/external/libhpdf/hpdf_font.h trunk/harbour/external/libhpdf/hpdf_font_cid.c trunk/harbour/external/libhpdf/hpdf_font_tt.c trunk/harbour/external/libhpdf/hpdf_font_type1.c trunk/harbour/external/libhpdf/hpdf_fontdef.c trunk/harbour/external/libhpdf/hpdf_fontdef.h trunk/harbour/external/libhpdf/hpdf_fontdef_base14.c trunk/harbour/external/libhpdf/hpdf_fontdef_cid.c trunk/harbour/external/libhpdf/hpdf_fontdef_cns.c trunk/harbour/external/libhpdf/hpdf_fontdef_cnt.c trunk/harbour/external/libhpdf/hpdf_fontdef_jp.c trunk/harbour/external/libhpdf/hpdf_fontdef_kr.c trunk/harbour/external/libhpdf/hpdf_fontdef_tt.c trunk/harbour/external/libhpdf/hpdf_fontdef_type1.c trunk/harbour/external/libhpdf/hpdf_gstate.c trunk/harbour/external/libhpdf/hpdf_gstate.h trunk/harbour/external/libhpdf/hpdf_image.c trunk/harbour/external/libhpdf/hpdf_image.h trunk/harbour/external/libhpdf/hpdf_image_png.c trunk/harbour/external/libhpdf/hpdf_info.c trunk/harbour/external/libhpdf/hpdf_info.h trunk/harbour/external/libhpdf/hpdf_list.c trunk/
Re: [Harbour] SF.net SVN: harbour-project:[10721] trunk/harbour
I have tried compiling tests c:\harbour\contrib\hbhpdf\tests>hbmk2 harupdf.prg hbhpdf.lib hbmk: Processing configuration: c:\harbour\mingw\bin\hbmk.cfg hbmk: Processing: hbhpdf.hbp Harbour 1.1.0dev (Rev. 10721) Copyright (c) 1999-2009, http://www.harbour-project.org/ Compiling 'harupdf.prg'... Lines 2245, Functions/Procedures 18 Generating C source output to 'harupdf.c'... Done. C:\devl\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cann t find -lhpdf collect2: ld returned 1 exit status hbmk: Error: Running C compiler. 1: 2009/3/29 : > Revision: 10721 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10721&view=rev > Author: vszakats > Date: 2009-03-29 09:09:24 + (Sun, 29 Mar 2009) > > Log Message: > --- > 2009-03-29 11:02 UTC+0200 Viktor Szakats (harbour.01 syenar hu) > * INSTALL > * external/Makefile > + external/libhpdf/* > + external/libpng/* > + Added libharu and libpng to Harbour repository. > Now it's possible to use libhpdf as static lib on all > platforms. This is useful because this lib isn't yet part > of Linux distros. > libpng is only built for win/dos/os2 platforms. > It's possible to override libpng location by using > HB_INC_LIBPNG envvar. > > * contrib/hbhpdf/Makefile > + Look for libharu headers in /external dir. > > * external/sqlite3/Makefile > - Disabled for bcc. Latest sqlite3 version breaks with this compiler: > --- > Error E2293 ../../sqlite3.c 29156: ) expected in function winCurrentTime > Warning W8013 ../../sqlite3.c 29157: Possible use of 'timeW' before > definition in function winCurrentTime > Error E2379 ../../sqlite3.c 29157: Statement missing ; in function > winCurrentTime > Error E2379 ../../sqlite3.c 29158: Statement missing ; in function > winCurrentTime > Error E2379 ../../sqlite3.c 29160: Statement missing ; in function > winCurrentTime > Error E2293 ../../sqlite3.c 29161: ) expected in function winCurrentTime > Error E2379 ../../sqlite3.c 29162: Statement missing ; in function > winCurrentTime > Error E2293 ../../sqlite3.c 29163: ) expected in function winCurrentTime > Warning W8057 ../../sqlite3.c 29171: Parameter 'prNow' is never used in > function winCurrentTime > *** 7 errors in Compile *** > --- > bcc users can report this problem here: > http://www.sqlite.org/cvstrac/tktnew > > + tests/bnch_win.bat > - tests/bnchmark > * Moved bnch_win.bat to tests. > > Modified Paths: > -- > trunk/harbour/ChangeLog > trunk/harbour/INSTALL > trunk/harbour/contrib/hbhpdf/Makefile > trunk/harbour/external/Makefile > trunk/harbour/external/sqlite3/Makefile > > Added Paths: > --- > trunk/harbour/external/libhpdf/ > trunk/harbour/external/libhpdf/Makefile > trunk/harbour/external/libhpdf/README > trunk/harbour/external/libhpdf/hpdf.h > trunk/harbour/external/libhpdf/hpdf_annotation.c > trunk/harbour/external/libhpdf/hpdf_annotation.h > trunk/harbour/external/libhpdf/hpdf_array.c > trunk/harbour/external/libhpdf/hpdf_binary.c > trunk/harbour/external/libhpdf/hpdf_boolean.c > trunk/harbour/external/libhpdf/hpdf_catalog.c > trunk/harbour/external/libhpdf/hpdf_catalog.h > trunk/harbour/external/libhpdf/hpdf_conf.h > trunk/harbour/external/libhpdf/hpdf_config.h > trunk/harbour/external/libhpdf/hpdf_consts.h > trunk/harbour/external/libhpdf/hpdf_destination.c > trunk/harbour/external/libhpdf/hpdf_destination.h > trunk/harbour/external/libhpdf/hpdf_dict.c > trunk/harbour/external/libhpdf/hpdf_doc.c > trunk/harbour/external/libhpdf/hpdf_doc.h > trunk/harbour/external/libhpdf/hpdf_doc_png.c > trunk/harbour/external/libhpdf/hpdf_encoder.c > trunk/harbour/external/libhpdf/hpdf_encoder.h > trunk/harbour/external/libhpdf/hpdf_encoder_cns.c > trunk/harbour/external/libhpdf/hpdf_encoder_cnt.c > trunk/harbour/external/libhpdf/hpdf_encoder_jp.c > trunk/harbour/external/libhpdf/hpdf_encoder_kr.c > trunk/harbour/external/libhpdf/hpdf_encrypt.c > trunk/harbour/external/libhpdf/hpdf_encrypt.h > trunk/harbour/external/libhpdf/hpdf_encryptdict.c > trunk/harbour/external/libhpdf/hpdf_encryptdict.h > trunk/harbour/external/libhpdf/hpdf_error.c > trunk/harbour/external/libhpdf/hpdf_error.h > trunk/harbour/external/libhpdf/hpdf_ext_gstate.c > trunk/harbour/external/libhpdf/hpdf_ext_gstate.h > trunk/harbour/external/libhpdf/hpdf_font.c > trunk/harbour/external/libhpdf/hpdf_font.h > trunk/harbour/external/libhpdf/hpdf_font_cid.c > trunk/harbour/external/libhpdf/hpdf_font_tt.c > trunk/harbour/external/libhpdf/hpdf_font_type1.c > trunk/harbour/external/libhpdf/hpdf_fontdef.c > trunk/harbour/external/libhpdf/hpdf_fontdef.h > trunk/harbour/external/libhpdf/hpdf_fontdef_base14.c > trunk/harbour/external/libhpdf/hpdf_fontdef_cid.c > trunk/harbour/external/libhpdf
Re: [Harbour] Re: XBASE++ speedtst
If we share a kit of executable of test on rapidshare (or in our web) this will be executed also from user that is not ready to compile so we have more comparison. 2009/3/29 Przemyslaw Czerpak : > On Sat, 28 Mar 2009, Angel Pais wrote: > > Hi, > >> this is the .bat file I use to compile Harbour. >> All the rest is pure svn code. >> compile.bat >> SET PATH=C:\vsk\vc\bin;C:\vsk\bin; >> SET LIB=C:\vsk\vc\lib;C:\vsk\lib; >> SET INCLUDE=C:\vsk\vc\include;C:\vsk\include; >> set HB_COMPILER=msvc >> set HB_INSTALL_PREFIX=C:\harbour >> set HB_VISUALC_VER=90 >> set HB_USER_CFLAGS=-DHB_FM_STATISTICS_OFF >> call make_gnu.bat clean > make_gnu_cln.txt >> call make_gnu.bat install > make_gnu_log.txt > > Thank you very much for confirmation. > Can you also check what will happen if you rebuild Harbour with: > set HB_USER_CFLAGS=-DHB_FM_STATISTICS_OFF -DHB_FM_WIN_ALLOC > > best regards, > Przemek > ___ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- Massimo Belgrano ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[10722] trunk/harbour
Revision: 10722 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10722&view=rev Author: vszakats Date: 2009-03-29 13:46:34 + (Sun, 29 Mar 2009) Log Message: --- 2009-03-29 15:46 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * bin/hb-mkdyn.sh * bin/hb-func.sh + Added support for .dll creation and hbmk for mingw64. * Synced Windows system liblist for dll creation. * wsock32 -> ws2_32 * bin/hb-mkdyn.bat ! wsock32 -> ws2_32 * contrib/gtwvg/gtwvg.c ! Fixed embedded ANSI C comments. * contrib/gtwvg/wvgsink.c ! Fixed a few non-ANSI C comments. * There is more, see: 'grep // *.c' Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/bin/hb-func.sh trunk/harbour/bin/hb-mkdyn.bat trunk/harbour/bin/hb-mkdyn.sh trunk/harbour/bin/postinst.sh trunk/harbour/contrib/gtwvg/gtwvg.c trunk/harbour/contrib/gtwvg/wvgsink.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[10688] trunk/harbour
> > BTW: in hbsetup.h you added: > ( defined(__POCC_TARGET__) && __POCC_TARGET__ == 2 ) > to detect HB_OS_WIN_CE builds. Maybe it's documented method in POCC > and in such case should be left but if not then I suggest to rather > use sth like: > ( defined( HB_OS_WIN ) && defined( _M_ARM ) ) Maybe I'm missing something, but _M_ARM doesn't seem to work in POCC 5, I've found no better solution back then, that's why I opted for this route. --- test.c #if defined( _M_ARM ) #error defined #else #error not defined #endif --- >pocc -Tarm-coff test.c -- Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[10723] trunk/harbour
Revision: 10723 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10723&view=rev Author: vouchcac Date: 2009-03-29 16:25:35 + (Sun, 29 Mar 2009) Log Message: --- 2009-03-29 09:03 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * harbour/contrib/gtwvg/wvgsink.c ! Fixed remaining non-ANSI C comments. Just had been overlooked! Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/gtwvg/wvgsink.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[10724] trunk/harbour
Revision: 10724 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10724&view=rev Author: druzus Date: 2009-03-29 17:13:52 + (Sun, 29 Mar 2009) Log Message: --- 2009-03-29 19:20 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbapi.h * harbour/include/hbstack.h * harbour/source/vm/estack.c * harbour/source/vm/fm.c + added support for thread local memory allocators by using MSPACE mechanism in DLALLOC. It can be enabled by compiling Harbour with HB_FM_DLMT_ALLOC macro. By default up to 16 (HB_MSPACE_COUNT macro) independent memory allocators is dynamically created for new threads. When more threads is used then allocators are shared between them and HVM tries to balance used allocators to reduce number of threads using the same allocator. It should give noticeable scalability improvement in some OS-es where default memory manages has pure MT performance. Please try to compiler speedtst.prg with Harbour compiled with and without HB_FM_DLMT_ALLOC and compare results in this test: speedtst --thread=2 --scale using real multiCPU machine. * harbour/source/vm/dlmalloc.c * pacified warning when FOOTERS are enabled * harbour/source/vm/garbage.c * cleanup comment Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/include/hbapi.h trunk/harbour/include/hbstack.h trunk/harbour/source/vm/dlmalloc.c trunk/harbour/source/vm/estack.c trunk/harbour/source/vm/fm.c trunk/harbour/source/vm/garbage.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: XBASE++ speedtst
On Sun, 29 Mar 2009, Przemyslaw Czerpak wrote: Hi, > > this is the .bat file I use to compile Harbour. > > All the rest is pure svn code. > > compile.bat > > SET PATH=C:\vsk\vc\bin;C:\vsk\bin; > > SET LIB=C:\vsk\vc\lib;C:\vsk\lib; > > SET INCLUDE=C:\vsk\vc\include;C:\vsk\include; > > set HB_COMPILER=msvc > > set HB_INSTALL_PREFIX=C:\harbour > > set HB_VISUALC_VER=90 > > set HB_USER_CFLAGS=-DHB_FM_STATISTICS_OFF > > call make_gnu.bat clean > make_gnu_cln.txt > > call make_gnu.bat install> make_gnu_log.txt > Thank you very much for confirmation. > Can you also check what will happen if you rebuild Harbour with: >set HB_USER_CFLAGS=-DHB_FM_STATISTICS_OFF -DHB_FM_WIN_ALLOC And if possible also with this settings: set HB_USER_CFLAGS=-DHB_FM_STATISTICS_OFF -DHB_FM_DLMT_ALLOC it should cause noticeable scalability improvement. The default DLMALLOC used in MSVC builds it's probably the worst possible choice for MT programs due to very bad scalability. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: XBASE++ speedtst
Here new set of results with download link included...
Please other windows users download and post results here
HTH
Angel
Przemyslaw Czerpak escribió:
Can you also check what will happen if you rebuild Harbour with:
set HB_USER_CFLAGS=-DHB_FM_STATISTICS_OFF -DHB_FM_WIN_ALLOC
best regards,
Przemek
Computer PIV Dual COre 3.0 win 2003 server, used tru VNC
03/29/2009 14:04:15 Windows XP 05.02 Build 03790
Xbase++ (R) Version 1.90 (MT)+
THREADS: 2
N_LOOPS: 100
1 th. 2 th. factor
[ T001: x := L_C ] 0.13 0.12 -> 1.08
[ T002: x := L_N ] 0.11 0.09 -> 1.22
[ T003: x := L_D ] 0.08 0.08 -> 1.00
[ T004: x := S_C ] 0.22 0.20 -> 1.10
[ T005: x := S_N ] 0.17 0.16 -> 1.06
[ T006: x := S_D ] 0.18 0.28 -> 0.64
[ T007: x := M->M_C ]_ 0.47 0.49 -> 0.96
[ T008: x := M->M_N ]_ 0.34 0.36 -> 0.94
[ T009: x := M->M_D ]_ 0.34 0.36 -> 0.94
[ T010: x := M->P_C ]_ 0.47 0.53 -> 0.89
[ T011: x := M->P_N ]_ 0.58 0.40 -> 1.45
[ T012: x := M->P_D ]_ 0.77 0.81 -> 0.95
[ T013: x := F_C ] 0.74 0.70 -> 1.06
[ T014: x := F_N ] 0.64 0.58 -> 1.10
[ T015: x := F_D ] 0.59 0.64 -> 0.92
[ T016: x := o:Args ]_ 0.42 0.47 -> 0.89
[ T017: x := o[2] ]___ 0.19 0.16 -> 1.19
[ T018: round( i / 1000, 2 ) ] 3.43 3.33 -> 1.03
[ T019: str( i / 1000 ) ]_ 21.55 21.41 -> 1.01
[ T020: val( s ) ] 0.96 1.00 -> 0.96
[ T021: val( a [ i % 16 + 1 ] ) ]_ 2.38 2.33 -> 1.02
[ T022: dtos( d - i % 1 ) ]___ 3.25 3.25 -> 1.00
[ T023: eval( { || i % 16 } ) ]___ 3.01 3.18 -> 0.95
[ T024: eval( bc := { || i % 16 } ) ]_ 1.78 1.68 -> 1.06
[ T025: eval( { |x| x % 16 }, i ) ]___ 1.38 1.41 -> 0.98
[ T026: eval( bc := { |x| x % 16 }, i ) ]_ 1.05 1.09 -> 0.96
[ T027: eval( { |x| f1( x ) }, i ) ]__ 1.56 1.71 -> 0.91
[ T028: eval( bc := { |x| f1( x ) }, i ) ] 1.42 1.55 -> 0.92
[ T029: eval( bc := &("{ |x| f1( x ) }"), i ) ]___ 2.04 1.99 -> 1.03
[ T030: x := &( 'f1(' + str(i) + ')' ) ]__ 60.67 60.14 -> 1.01
[ T031: bc := &( '{|x|f1(x)}' ), eval( bc, i ) ]__ 61.03 61.48 -> 0.99
[ T032: x := valtype( x ) + valtype( i ) ]___ 1.02 0.90 -> 1.13
[ T033: x := strzero( i % 100, 2 ) $ a[ i % 16 + 1 ] ] 23.69 23.80 -> 1.00
[ T034: x := a[ i % 16 + 1 ] == s ]___ 0.90 0.94 -> 0.96
[ T035: x := a[ i % 16 + 1 ] = s ] 1.36 1.38 -> 0.99
[ T036: x := a[ i % 16 + 1 ] >= s ]___ 1.35 1.38 -> 0.98
[ T037: x := a[ i % 16 + 1 ] <= s ]___ 1.33 1.40 -> 0.95
[ T038: x := a[ i % 16 + 1 ] < s ] 1.32 1.35 -> 0.98
[ T039: x := a[ i % 16 + 1 ] > s ] 1.26 1.36 -> 0.93
[ T040: ascan( a, i % 16 ) ]__ 2.11 2.10 -> 1.00
[ T041: ascan( a, { |x| x == i % 16 } ) ]_ 14.21 14.74 -> 0.96
[ T042: iif( i%1000==0, a:={}, ), aadd(a,{i,1,.t.,s, ] 20.09 20.55 -> 0.98
[ T043: x := a ]__ 0.12 0.11 -> 1.09
[ T044: x := {} ]_ 1.18 1.46 -> 0.81
[ T045: f0() ] 0.47 0.35 -> 1.34
[ T046: f1( i ) ]_ 0.54 0.47 -> 1.15
[ T047: f2( c[1...8] ) ]__ 0.42 0.43 -> 0.98
[ T048: f2( c[1...4] ) ]__ 0.45 0.45 -> 1.00
[ T049: f2( @c[1...4] ) ]_ 0.38 0.39 -> 0.97
[ T050: f2( @c[1...4] ), c2 := c ] 0.51 0.60 -> 0.85
[ T051: f3( a, a2, s, i, s2, bc, i, n, x ) ]__ 0.83 0.76 -> 1.09
[ T052: f2( a ) ]_ 0.41 0.40 -> 1.02
[ T053: x := f4() ]___ 2.72 2.63 -> 1.03
[ T054: x := f5() ]___ 1.22 1.26 -> 0.97
[ T055: x := space(16) ]__ 0.85 0.84 -> 1.01
[ T056: f_prv( c ) ]__ 1.43 1.39 -> 1.03
===
[Harbour] SF.net SVN: harbour-project:[10725] trunk/harbour
Revision: 10725 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10725&view=rev Author: druzus Date: 2009-03-29 17:51:15 + (Sun, 29 Mar 2009) Log Message: --- 2009-03-29 19:57 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/source/vm/fm.c ! fixed typo and add missing HVM stack preload macros Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/source/vm/fm.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[10726] trunk/harbour
Revision: 10726 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10726&view=rev Author: vszakats Date: 2009-03-29 17:55:37 + (Sun, 29 Mar 2009) Log Message: --- 2009-03-29 19:52 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * external/sqlite3/Makefile ! Added necessary configuration for WinCE builds. * bin/hb-func.sh * source/vm/maindllp.c * mingwce will now generate dll by the name: harbour*-*-arm.dll ; TOFIX: mingwce .dlls should probably be generated in bin dir just like in every other cases, but I don't know why it's explicitly put in lib dir in this case. * bin/hb-mkdyn.bat + Added .dll generation for msvcce and poccce. * source/vm/maindllp.c * Formatting. ! Fixed to compile for WinCE. Please review me. * contrib/hbct/disk.c ! DRIVETYPE() made a dummy under WinCE to make it compile. * contrib/gtwvg/Makefile ! Limited GTWVG builds to 32-bit Windows compilers as it's still broken for WinCE, this time with pocce. Notice HB_OS* macros aren't available before #including Harbour headers. Reenable them after being fixed and tested. * contrib/hbole/olecore.c ! Fixed compilation errors below with poccce. Please review me. pocc.exe -I. -Ze -Go -W1 -Ot -Tarm-coff -D_WINCE -DUNICODE -DHB_NO_WIN_CONSOLE -I../../../../include -c ../../olecore.c -Foolecore.obj ../../olecore.c(188): error #2152: Unknown field 'llVal' of 'union (no name)'. ../../olecore.c(273): error #2152: Unknown field 'llVal' of 'union (no name)'. ../../olecore.c(290): error #2152: Unknown field 'ullVal' of 'union (no name)'. * contrib/hbsqlit3/Makefile ! Excluded for poccce. ; TOFIX: pocc.exe -I. -Ze -Go -W1 -Ot -Tarm-coff -D_WINCE -DUNICODE -DHB_NO_WIN_CONSOLE -I../../../../include -c ../../getenvrn.c -Fogetenvrn.obj ../../getenvrn.c(177): warning #2027: Missing prototype for 'GetEnvironmentStrings'. ../../getenvrn.c(177): error #2168: Operands of = have incompatible types 'wchar_t *' and 'int'. ../../getenvrn.c(246): warning #2027: Missing prototype for 'FreeEnvironmentStrings'. pocc.exe -I. -Ze -Go -W1 -Ot -Tarm-coff -D_WINCE -DUNICODE -DHB_NO_WIN_CONSOLE -I../../../../include -c ../../hbserv.c -Fohbserv.obj ../../hbserv.c(391): error #2048: Undeclared identifier 'CTRL_C_EVENT'. ../../hbserv.c(392): error #2048: Undeclared identifier 'CTRL_BREAK_EVENT'. ../../hbserv.c(393): error #2048: Undeclared identifier 'CTRL_CLOSE_EVENT'. ../../hbserv.c(394): error #2048: Undeclared identifier 'CTRL_LOGOFF_EVENT'. ../../hbserv.c(395): error #2048: Undeclared identifier 'CTRL_SHUTDOWN_EVENT'. ../../hbserv.c(398): error #2069: Initializer must be constant. ../../hbserv.c(511): warning #2027: Missing prototype for 'CallNextHookEx'. ../../hbserv.c(528): warning #2027: Missing prototype for 'CallNextHookEx'. ../../hbserv.c(635): error #2048: Undeclared identifier 'SEM_NOALIGNMENTFAULTEXCEPT'. ../../hbserv.c(635): error #2048: Undeclared identifier 'SEM_NOGPFAULTERRORBOX'. ../../hbserv.c(636): error #2048: Undeclared identifier 'SEM_NOOPENFILEERRORBOX'. ../../hbserv.c(638): warning #2027: Missing prototype for 'SetUnhandledExceptionFilter'. ../../hbserv.c(639): warning #2027: Missing prototype for 'SetWindowsHookEx'. ../../hbserv.c(639): error #2048: Undeclared identifier 'WH_GETMESSAGE'. ../../hbserv.c(639): error #2048: Undeclared identifier 'HOOKPROC'. ../../hbserv.c(639): error #2001: Syntax error: expected ')' but found 's_MsgFilterFunc'. ../../hbserv.c(639): error #2168: Operands of = have incompatible types 'HHOOK' and 'int'. ../../hbserv.c(639): error #2001: Syntax error: expected ';' but found 's_MsgFilterFunc'. ../../hbserv.c(639): error #2001: Syntax error: expected ';' but found ')'. ../../hbserv.c(639): error #2061: Illegal statement termination. ../../hbserv.c(640): warning #2027: Missing prototype for 'SetConsoleCtrlHandler'. ../../hbserv.c(665): warning #2027: Missing prototype for 'SetUnhandledExceptionFilter'. ../../hbserv.c(668): warning #2027: Missing prototype for 'UnhookWindowsHookEx'. ../../hbserv.c(672): warning #2027: Missing prototype for 'SetConsoleCtrlHandler'. ../../hbserv.c(776): warning #2027: Missing prototype for 'FreeConsole'. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/bin/hb-func.sh trunk/harbour/bin/hb-mkdyn.bat trunk/harbour/contrib/gtwvg/Makefile trunk/harbour/contrib/hbct/disk.c trunk/harbour/contrib/hbole/olecore.c trunk/harbour/contrib/hbsqlit3/Makefile trunk/harbour/external/sqlite3/Makefile trunk/harbour/source/vm/maindllp.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
[Harbour] Re: SF.net SVN: harbour-project:[10724] trunk/harbour
I couldn't recompile harbour Here the error: cl.exe -nologo -I. -I../../../../../include -Gs -TP -W4 -wd4127 -Ot2b1 -EHs-c- -MT -DHB_FM_STATISTICS_OFF -DHB_FM_DLMT_ALLOC -DHB_MT_VM -c ../../../fm.c -Fofm.obj fm.c ../../../fm.c(403) : error C2440: '=' : cannot convert from 'mspace' to 'mspace *' Conversion from 'void*' to pointer to non-'void' requires an explicit cast ../../../fm.c(415) : error C2440: '=' : cannot convert from 'mspace' to 'mspace *' Conversion from 'void*' to pointer to non-'void' requires an explicit cast Regards Angel dru...@users.sourceforge.net escribió: Revision: 10724 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10724&view=rev Author: druzus Date: 2009-03-29 17:13:52 + (Sun, 29 Mar 2009) Log Message: --- 2009-03-29 19:20 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbapi.h * harbour/include/hbstack.h * harbour/source/vm/estack.c * harbour/source/vm/fm.c + added support for thread local memory allocators by using MSPACE mechanism in DLALLOC. It can be enabled by compiling Harbour with HB_FM_DLMT_ALLOC macro. By default up to 16 (HB_MSPACE_COUNT macro) independent memory allocators is dynamically created for new threads. When more threads is used then allocators are shared between them and HVM tries to balance used allocators to reduce number of threads using the same allocator. It should give noticeable scalability improvement in some OS-es where default memory manages has pure MT performance. Please try to compiler speedtst.prg with Harbour compiled with and without HB_FM_DLMT_ALLOC and compare results in this test: speedtst --thread=2 --scale using real multiCPU machine. * harbour/source/vm/dlmalloc.c * pacified warning when FOOTERS are enabled * harbour/source/vm/garbage.c * cleanup comment Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/include/hbapi.h trunk/harbour/include/hbstack.h trunk/harbour/source/vm/dlmalloc.c trunk/harbour/source/vm/estack.c trunk/harbour/source/vm/fm.c trunk/harbour/source/vm/garbage.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: XBASE++ speedtst
On Sun, 29 Mar 2009, Angel Pais wrote: Hi, > Here new set of results with download link included... > Please other windows users download and post results here Thank you very much. > Computer PIV Dual COre 3.0 win 2003 server, used tru VNC > 03/29/2009 14:04:15 Windows XP 05.02 Build 03790 > Xbase++ (R) Version 1.90 (MT)+ > THREADS: 2 > N_LOOPS: 100 > > [ T001: x := L_C ] 0.13 0.12 -> 1.08 > [ T002: x := L_N ] 0.11 0.09 -> 1.22 > [ T003: x := L_D ] 0.08 0.08 -> 1.00 > [ T004: x := S_C ] 0.22 0.20 -> 1.10 > [ T005: x := S_N ] 0.17 0.16 -> 1.06 > [ T006: x := S_D ] 0.18 0.28 -> 0.64 > [ T007: x := M->M_C ]_ 0.47 0.49 -> 0.96 > [ T008: x := M->M_N ]_ 0.34 0.36 -> 0.94 > [ T009: x := M->M_D ]_ 0.34 0.36 -> 0.94 > [ T010: x := M->P_C ]_ 0.47 0.53 -> 0.89 > [ T011: x := M->P_N ]_ 0.58 0.40 -> 1.45 > [ T012: x := M->P_D ]_ 0.77 0.81 -> 0.95 > [ T013: x := F_C ] 0.74 0.70 -> 1.06 > [ T014: x := F_N ] 0.64 0.58 -> 1.10 > [ T015: x := F_D ] 0.59 0.64 -> 0.92 > [ T016: x := o:Args ]_ 0.42 0.47 -> 0.89 > [ T017: x := o[2] ]___ 0.19 0.16 -> 1.19 > [ T018: round( i / 1000, 2 ) ] 3.43 3.33 -> 1.03 > [ T019: str( i / 1000 ) ]_ 21.55 21.41 -> 1.01 > [ T020: val( s ) ] 0.96 1.00 -> 0.96 [...] > > [ TOTAL ]_252.12 253.42 -> 0.99 > > [ total application time: ]...505.66 > [ total real time: ]..505.66 > It went ok, however only processor 1 was at 100% So they assigned the process to single CPU. > set HB_USER_CFLAGS=-DHB_FM_STATISTICS_OFF > 03/29/09 14:12:42 Windows Server 2003 / XP x64 5.2.3790 > Harbour 1.1.0dev (Rev. 10718) (MT)+ Microsoft Visual C++ 14.0.24999 (32-bit) > THREADS: 2 > N_LOOPS: 100 > 1 th. 2 th. factor > > [ T001: x := L_C ] 0.28 0.25 -> 1.13 > [ T002: x := L_N ] 0.19 0.16 -> 1.20 > [ T003: x := L_D ] 0.16 0.19 -> 0.84 > [ T004: x := S_C ] 0.30 0.27 -> 1.12 > [ T005: x := S_N ] 0.19 0.19 -> 0.99 > [ T006: x := S_D ] 0.22 0.19 -> 1.16 > [ T007: x := M->M_C ]_ 0.33 0.31 -> 1.05 > [ T008: x := M->M_N ]_ 0.25 0.23 -> 1.07 > [ T009: x := M->M_D ]_ 0.22 0.22 -> 1.00 > [ T010: x := M->P_C ]_ 0.27 0.27 -> 1.00 > [ T011: x := M->P_N ]_ 0.22 0.25 -> 0.88 > [ T012: x := M->P_D ]_ 0.23 0.24 -> 1.00 > [ T013: x := F_C ] 0.88 0.83 -> 1.06 > [ T014: x := F_N ] 0.72 0.66 -> 1.09 > [ T015: x := F_D ] 0.41 0.38 -> 1.08 > [ T016: x := o:Args ]_ 0.64 0.69 -> 0.93 > [ T017: x := o[2] ]___ 0.44 0.47 -> 0.93 > [ T018: round( i / 1000, 2 ) ] 0.72 0.64 -> 1.12 > [ T019: str( i / 1000 ) ]_ 1.80 1.59 -> 1.13 > [ T020: val( s ) ] 0.94 0.89 -> 1.05 [...] > > [ TOTAL ]_228.59 294.75 -> 0.78 > > [ total application time: ]...689.98 > [ total real time: ]..523.52 > Both processors at 100%, occasionally 1st. proc was at 60% And here we have _FATAL_ scalability results. It's very strange for me. In most of above tests non
Re: [Harbour] Re: SF.net SVN: harbour-project:[10724] trunk/harbour
On Sun, 29 Mar 2009, Angel Pais wrote: Hi, > I couldn't recompile harbour > Here the error: > cl.exe -nologo -I. -I../../../../../include -Gs -TP -W4 -wd4127 -Ot2b1 > -EHs-c- -MT -DHB_FM_STATISTICS_OFF -DHB_FM_DLMT_ALLOC -DHB_MT_VM -c > ../../../fm.c -Fofm.obj > fm.c > ../../../fm.c(403) : error C2440: '=' : cannot convert from 'mspace' to > 'mspace *' > Conversion from 'void*' to pointer to non-'void' requires an > explicit cast > ../../../fm.c(415) : error C2440: '=' : cannot convert from 'mspace' to > 'mspace *' > Conversion from 'void*' to pointer to non-'void' requires an > explicit cast I've just fixed it but it will not help to improve scalability in your case. I've just seen you full results from previous tests. Please look at my answer. I'd rather look for some switch which enables/disables dynamic CPU clock update. It's also possible that your results are limited by hardware and when two CPU are used then the the do not give linear speed improvement. I'm not hardware specialist so I cannot say too much about different PIV constructions. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[10724] trunk/harbour
Awesome
I don't know if scalability is better but processor time went down from
100% to 62% in average on same machine.
Also sacalability improved a little
See attached...
If my compiling settings are ok I can upload a new set of tests to
rapidshare including this last one.
HTH
Angel
PD: I know almost nothing about hardware sorry. This machine is a
production server I have.
PD2: My next app server will be in SUSE + Harbour I hope ;)
Przemyslaw Czerpak escribió:
On Sun, 29 Mar 2009, Angel Pais wrote:
Hi,
I couldn't recompile harbour
Here the error:
cl.exe -nologo -I. -I../../../../../include -Gs -TP -W4 -wd4127 -Ot2b1
-EHs-c- -MT -DHB_FM_STATISTICS_OFF -DHB_FM_DLMT_ALLOC -DHB_MT_VM -c
../../../fm.c -Fofm.obj
fm.c
../../../fm.c(403) : error C2440: '=' : cannot convert from 'mspace' to
'mspace *'
Conversion from 'void*' to pointer to non-'void' requires an
explicit cast
../../../fm.c(415) : error C2440: '=' : cannot convert from 'mspace' to
'mspace *'
Conversion from 'void*' to pointer to non-'void' requires an
explicit cast
I've just fixed it but it will not help to improve scalability in your
case. I've just seen you full results from previous tests.
Please look at my answer. I'd rather look for some switch which
enables/disables dynamic CPU clock update. It's also possible that
your results are limited by hardware and when two CPU are used then
the the do not give linear speed improvement. I'm not hardware
specialist so I cannot say too much about different PIV constructions.
best regards,
Przemek
Compiler and Enviroment:
set HB_COMPILER=msvc
set HB_VISUALC_VER=90
set HB_USER_CFLAGS=-DHB_FM_STATISTICS_OFF -DHB_FM_DLMT_ALLOC
Program built with: hbmk2.exe speedtst.prg -mt -gc3 -b -l -ko
03/29/09 15:42:55 Windows Server 2003 / XP x64 5.2.3790
Harbour 1.1.0dev (Rev. 10718) (MT)+ Microsoft Visual C++ 14.0.24999 (32-bit)
THREADS: 2
N_LOOPS: 100
1 th. 2 th. factor
[ T001: x := L_C ] 0.30 0.23 -> 1.27
[ T002: x := L_N ] 0.19 0.17 -> 1.09
[ T003: x := L_D ] 0.16 0.14 -> 1.12
[ T004: x := S_C ] 0.28 0.30 -> 0.95
[ T005: x := S_N ] 0.19 0.17 -> 1.09
[ T006: x := S_D ] 0.19 0.16 -> 1.20
[ T007: x := M->M_C ]_ 0.33 0.30 -> 1.11
[ T008: x := M->M_N ]_ 0.22 0.20 -> 1.08
[ T009: x := M->M_D ]_ 0.25 0.20 -> 1.23
[ T010: x := M->P_C ]_ 0.27 0.25 -> 1.06
[ T011: x := M->P_N ]_ 0.25 0.20 -> 1.23
[ T012: x := M->P_D ]_ 0.22 0.19 -> 1.17
[ T013: x := F_C ] 0.84 0.97 -> 0.87
[ T014: x := F_N ] 0.70 0.56 -> 1.25
[ T015: x := F_D ] 0.36 0.38 -> 0.96
[ T016: x := o:Args ]_ 0.59 0.59 -> 1.00
[ T017: x := o[2] ]___ 0.45 0.38 -> 1.21
[ T018: round( i / 1000, 2 ) ] 0.70 0.59 -> 1.18
[ T019: str( i / 1000 ) ]_ 1.83 1.72 -> 1.06
[ T020: val( s ) ] 0.92 0.77 -> 1.20
[ T021: val( a [ i % 16 + 1 ] ) ]_ 1.61 1.48 -> 1.08
[ T022: dtos( d - i % 1 ) ]___ 1.64 1.38 -> 1.19
[ T023: eval( { || i % 16 } ) ]___ 6.34 9.00 -> 0.70
[ T024: eval( bc := { || i % 16 } ) ]_ 4.76 6.06 -> 0.79
[ T025: eval( { |x| x % 16 }, i ) ]___ 5.42 7.58 -> 0.72
[ T026: eval( bc := { |x| x % 16 }, i ) ]_ 4.72 5.78 -> 0.82
[ T027: eval( { |x| f1( x ) }, i ) ]__ 10.48 14.94 -> 0.70
[ T028: eval( bc := { |x| f1( x ) }, i ) ] 9.47 13.17 -> 0.72
[ T029: eval( bc := &("{ |x| f1( x ) }"), i ) ]___ 4.42 5.44 -> 0.81
Compiler and Enviroment:
set HB_COMPILER=msvc
set HB_VISUALC_VER=90
set HB_USER_CFLAGS=-DHB_FM_STATISTICS_OFF -DHB_FM_DLMT_ALLOC
Program built with: hbmk2.exe speedtst.prg -mt -gc3 -b -l -ko
03/29/09 16:11:48 Windows Server 2003 / XP x64 5.2.3790
Harbour 1.1.0dev (Rev. 10726) (MT)+ Microsoft Visual C++ 14.0.24999 (32-bit)
THREADS: 2
N_LOOPS: 100
1 th. 2 th. factor
[ T001: x := L_C ] 0.28 0.25 -> 1.13
[ T002: x := L_N ] 0.16 0.14 -> 1.11
[ T003: x := L_D ]_
Re: [Harbour] Re: SF.net SVN: harbour-project:[10724] trunk/harbour
On Sun, 29 Mar 2009, Angel Pais wrote: Hi, > I don't know if scalability is better but processor time went down from > 100% to 62% in average on same machine. > Also sacalability improved a little > See attached... > Compiler and Enviroment: > set HB_COMPILER=msvc > set HB_VISUALC_VER=90 > set HB_USER_CFLAGS=-DHB_FM_STATISTICS_OFF -DHB_FM_DLMT_ALLOC > Program built with: hbmk2.exe speedtst.prg -mt -gc3 -b -l -ko do not use -b switch !!!. It enables debug builds where some additional PCODEs are generated which may cause fatal performance reduction. It also causes that -l is ignored but it's minor overhead in comparison to other things enabled by -b. Please try to repeat this test without -b: hbmk2.exe speedtst.prg -mt -gc3 -l -ko and if possible please upload such Harbour and XBASE++ binaries. Thank you very much for your tests. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[10724] trunk/harbour
Oops ! Then I wil have to re compile harbour with the 3 mem allocator switches and to all tests again. No problem. It was my fault. Will try to finish them today. Regards Angel Przemyslaw Czerpak escribió: On Sun, 29 Mar 2009, Angel Pais wrote: Hi, I don't know if scalability is better but processor time went down from 100% to 62% in average on same machine. Also sacalability improved a little See attached... Compiler and Enviroment: set HB_COMPILER=msvc set HB_VISUALC_VER=90 set HB_USER_CFLAGS=-DHB_FM_STATISTICS_OFF -DHB_FM_DLMT_ALLOC Program built with: hbmk2.exe speedtst.prg -mt -gc3 -b -l -ko do not use -b switch !!!. It enables debug builds where some additional PCODEs are generated which may cause fatal performance reduction. It also causes that -l is ignored but it's minor overhead in comparison to other things enabled by -b. Please try to repeat this test without -b: hbmk2.exe speedtst.prg -mt -gc3 -l -ko and if possible please upload such Harbour and XBASE++ binaries. Thank you very much for your tests. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[10727] trunk/harbour
Revision: 10727 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10727&view=rev Author: druzus Date: 2009-03-29 20:00:33 + (Sun, 29 Mar 2009) Log Message: --- 2009-03-29 22:07 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/tests/speedtst.prg * added warning message when HVM debugger is enabled Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/tests/speedtst.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[10724] trunk/harbour
if upload rapidstare i try This is correct ? speedxpp.exe --thread=2 --scale >T.TXT speedhb1.exe --thread=2 --scale >> T.TXT speedhb2.exe --thread=2 --scale >> t.txt 2009/3/29 Angel Pais : > Oops ! > Then I wil have to re compile harbour with the 3 mem allocator switches and > to all tests again. > No problem. It was my fault. Will try to finish them today. > > Regards > Angel > > Przemyslaw Czerpak escribió: >> >> On Sun, 29 Mar 2009, Angel Pais wrote: >> >> Hi, >> >>> I don't know if scalability is better but processor time went down from >>> 100% to 62% in average on same machine. >>> Also sacalability improved a little >>> See attached... >>> Compiler and Enviroment: >>> set HB_COMPILER=msvc >>> set HB_VISUALC_VER=90 >>> set HB_USER_CFLAGS=-DHB_FM_STATISTICS_OFF -DHB_FM_DLMT_ALLOC >>> Program built with: hbmk2.exe speedtst.prg -mt -gc3 -b -l -ko >> >> do not use -b switch !!!. It enables debug builds where some additional >> PCODEs are generated which may cause fatal performance reduction. >> It also causes that -l is ignored but it's minor overhead in comparison >> to other things enabled by -b. >> Please try to repeat this test without -b: >> hbmk2.exe speedtst.prg -mt -gc3 -l -ko >> and if possible please upload such Harbour and XBASE++ binaries. >> >> Thank you very much for your tests. >> >> best regards, >> Przemek > > ___ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- Massimo Belgrano ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[10724] trunk/harbour
On Sun, 29 Mar 2009, Angel Pais wrote: Hi, > Oops ! > Then I wil have to re compile harbour with the 3 mem allocator switches and > to all tests again. > No problem. It was my fault. Will try to finish them today. My too. I've just added warning to speedtst result messages which informs about enabled debugger. It also explains why in your results used memory manager changed the results in tests which normally do not allocate any memory. Just simply when debugger is enabled some additional code is executed to store execution context and this code allocates memory. In Clipper and [x]Harbour debugger code compiled with -b reduce the performance. I guess that sth like that can happen also in xbase++ so all tests should be compiled without -b or other debug options. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[10724] trunk/harbour
Wait till new upload. And yes, each exe is a different compiler setting. No need to redirect anything cause set alternate is additive. Regards Angel Massimo Belgrano escribió: if upload rapidstare i try This is correct ? speedxpp.exe --thread=2 --scale >T.TXT speedhb1.exe --thread=2 --scale >> T.TXT speedhb2.exe --thread=2 --scale >> t.txt ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[10724] trunk/harbour
Performance went to the sky ! Scalability not so much... Preliminary results here (2 consecutive runs). Will recompile harbour with all 3 mem allocators and upload binaries to rapidshare. HTH Angel Przemyslaw Czerpak escribió: On Sun, 29 Mar 2009, Angel Pais wrote: Hi, Oops ! Then I wil have to re compile harbour with the 3 mem allocator switches and to all tests again. No problem. It was my fault. Will try to finish them today. My too. I've just added warning to speedtst result messages which informs about enabled debugger. It also explains why in your results used memory manager changed the results in tests which normally do not allocate any memory. Just simply when debugger is enabled some additional code is executed to store execution context and this code allocates memory. In Clipper and [x]Harbour debugger code compiled with -b reduce the performance. I guess that sth like that can happen also in xbase++ so all tests should be compiled without -b or other debug options. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[10724] trunk/harbour
Forgot the attachment... =D
Angel Pais escribió:
Performance went to the sky !
Scalability not so much...
Preliminary results here (2 consecutive runs).
Will recompile harbour with all 3 mem allocators and upload binaries to
rapidshare.
HTH
Angel
Compiler and Enviroment:
set HB_COMPILER=msvc
set HB_VISUALC_VER=90
set HB_USER_CFLAGS=-DHB_FM_STATISTICS_OFF -DHB_FM_DLMT_ALLOC
Program built with: hbmk2.exe speedtst.prg -mt -gc3 -l -ko
03/29/09 17:58:22 Windows Server 2003 / XP x64 5.2.3790
Harbour 1.1.0dev (Rev. 10726) (MT)+ Microsoft Visual C++ 14.0.24999 (32-bit)
THREADS: 2
N_LOOPS: 100
1 th. 2 th. factor
[ T001: x := L_C ] 0.31 0.25 -> 1.25
[ T002: x := L_N ] 0.16 0.16 -> 1.01
[ T003: x := L_D ] 0.16 0.19 -> 0.83
[ T004: x := S_C ] 0.28 0.30 -> 0.95
[ T005: x := S_N ] 0.22 0.19 -> 1.16
[ T006: x := S_D ] 0.17 0.19 -> 0.92
[ T007: x := M->M_C ]_ 0.34 0.34 -> 1.00
[ T008: x := M->M_N ]_ 0.25 0.20 -> 1.23
[ T009: x := M->M_D ]_ 0.28 0.20 -> 1.38
[ T010: x := M->P_C ]_ 0.28 0.28 -> 1.00
[ T011: x := M->P_N ]_ 0.23 0.24 -> 1.00
[ T012: x := M->P_D ]_ 0.23 0.20 -> 1.15
[ T013: x := F_C ] 0.91 0.84 -> 1.07
[ T014: x := F_N ] 0.73 0.70 -> 1.04
[ T015: x := F_D ] 0.36 0.36 -> 1.00
[ T016: x := o:Args ]_ 0.59 0.58 -> 1.03
[ T017: x := o[2] ]___ 0.42 0.44 -> 0.96
[ T018: round( i / 1000, 2 ) ] 0.73 0.55 -> 1.34
[ T019: str( i / 1000 ) ]_ 1.81 1.64 -> 1.10
[ T020: val( s ) ] 0.91 0.88 -> 1.04
[ T021: val( a [ i % 16 + 1 ] ) ]_ 1.55 1.38 -> 1.13
[ T022: dtos( d - i % 1 ) ]___ 1.67 1.48 -> 1.13
[ T023: eval( { || i % 16 } ) ]___ 2.36 2.13 -> 1.11
[ T024: eval( bc := { || i % 16 } ) ]_ 0.97 0.84 -> 1.15
[ T025: eval( { |x| x % 16 }, i ) ]___ 1.76 1.56 -> 1.13
[ T026: eval( bc := { |x| x % 16 }, i ) ]_ 1.09 0.89 -> 1.23
[ T027: eval( { |x| f1( x ) }, i ) ]__ 1.89 1.66 -> 1.14
[ T028: eval( bc := { |x| f1( x ) }, i ) ] 1.08 0.97 -> 1.11
[ T029: eval( bc := &("{ |x| f1( x ) }"), i ) ]___ 1.09 0.97 -> 1.13
[ T030: x := &( "f1(" + str(i) + ")" ) ]__ 13.38 15.03 -> 0.89
[ T031: bc := &( "{|x|f1(x)}" ), eval( bc, i ) ]__ 16.36 16.97 -> 0.96
[ T032: x := valtype( x ) + valtype( i ) ]___ 1.56 1.47 -> 1.06
[ T033: x := strzero( i % 100, 2 ) $ a[ i % 16 + 1 ] ] 2.81 2.59 -> 1.08
[ T034: x := a[ i % 16 + 1 ] == s ]___ 1.28 1.14 -> 1.12
[ T035: x := a[ i % 16 + 1 ] = s ] 1.38 1.22 -> 1.13
[ T036: x := a[ i % 16 + 1 ] >= s ]___ 1.33 1.22 -> 1.09
[ T037: x := a[ i % 16 + 1 ] <= s ]___ 1.26 1.20 -> 1.05
[ T038: x := a[ i % 16 + 1 ] < s ] 1.30 1.27 -> 1.02
[ T039: x := a[ i % 16 + 1 ] > s ] 1.26 1.25 -> 1.01
[ T040: ascan( a, i % 16 ) ]__ 1.19 1.16 -> 1.03
[ T041: ascan( a, { |x| x == i % 16 } ) ]_ 11.64 9.92 -> 1.17
[ T042: iif( i%1000==0, a:={}, ) , aadd(a,{i,1,.T.,s ] 4.16 3.73 -> 1.11
[ T043: x := a ]__ 0.31 0.28 -> 1.11
[ T044: x := {} ]_ 1.00 1.05 -> 0.96
[ T045: f0() ] 0.33 0.28 -> 1.17
[ T046: f1( i ) ]_ 0.41 0.38 -> 1.08
[ T047: f2( c[1...8] ) ]__ 0.55 0.45 -> 1.21
[ T048: f2( c[1...4] ) ]__ 0.56 0.45 -> 1.24
[ T049: f2( @c[1...4] ) ]_ 0.38 0.41 -> 0.92
[ T050: f2( @c[1...4] ), c2 := c ] 0.61 0.55 -> 1.11
[ T051: f3( a, a2, s, i, s2, bc, i, n, x ) ]__ 1.63 1.50 -> 1.08
[ T052: f2( a ) ]_ 0.58 0.45 -> 1.27
[ T053: x := f4() ]___ 2.70 2.80 -> 0.97
[ T054: x := f5() ]___ 1.24 1.16 -> 1.07
[ T055: x := space(16) ]__ 1.09 1.01 -> 1.08
[ T05
[Harbour] SF.net SVN: harbour-project:[10728] trunk/harbour
Revision: 10728 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10728&view=rev Author: vszakats Date: 2009-03-29 20:53:47 + (Sun, 29 Mar 2009) Log Message: --- 2009-03-29 22:26 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * config/dos/owatcom.cf * config/win/owatcom.cf * config/linux/owatcom.cf * config/os2/owatcom.cf % Tweaked optimization options. This will result in slower build process, but more optimal runtime performance and executable sizes. One option is now turned on which can cause bad code with OW 1.1, so make sure you use latest Open Watcom version, after all the upgrade is free. It'd be great if owatcom users could make speedtst runs with this revision and older ones to see the difference, maybe now owatcom won't perform so poorly as before. + Added link to C compiler option docs. ! Fixed to convert slashes in HB_USER_CFLAGS. % Enabled -5r for DOS and OS/2. * contrib/hbct/disk.c ! Disabled some volume/disk related code for WinCE. * contrib/xhb/hbserv.c ! Disabled for poccce. * contrib/hbnf/getenvrn.c ! Disabled FT_GETE() for poccce. ! Fixed FT_GETE() to return zero/empty string on platforms not supported (like also OS/2). * doc/en-EN/Makefile - doc/en-EN/error.txt + doc/en-EN/errsys.txt * source/rtl/Makefile - source/rtl/fserror.c - source/rtl/errorapi.c - source/rtl/errorapu.c - source/rtl/errorint.c - source/rtl/errorsys.prg + source/rtl/fserr.c + source/rtl/errapi.c + source/rtl/errint.c + source/rtl/errapiu.c + source/rtl/errsys.prg * contrib/examples/hbdoc/examples/core_es/Makefile - contrib/examples/hbdoc/examples/core_es/error.txt + contrib/examples/hbdoc/examples/core_es/errsys.txt * Most filenames containing 'error' renamed to make it easier to search for errors in build logs. ; Three headers remain. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/config/dos/owatcom.cf trunk/harbour/config/linux/owatcom.cf trunk/harbour/config/os2/owatcom.cf trunk/harbour/config/win/owatcom.cf trunk/harbour/contrib/examples/hbdoc/examples/core_es/Makefile trunk/harbour/contrib/hbct/disk.c trunk/harbour/contrib/hbnf/getenvrn.c trunk/harbour/contrib/xhb/hbserv.c trunk/harbour/doc/en-EN/Makefile trunk/harbour/source/rtl/Makefile Added Paths: --- trunk/harbour/contrib/examples/hbdoc/examples/core_es/errsys.txt trunk/harbour/doc/en-EN/errsys.txt trunk/harbour/source/rtl/errapi.c trunk/harbour/source/rtl/errapiu.c trunk/harbour/source/rtl/errint.c trunk/harbour/source/rtl/errsys.prg trunk/harbour/source/rtl/fserr.c Removed Paths: - trunk/harbour/contrib/examples/hbdoc/examples/core_es/error.txt trunk/harbour/doc/en-EN/error.txt trunk/harbour/source/rtl/errorapi.c trunk/harbour/source/rtl/errorapu.c trunk/harbour/source/rtl/errorint.c trunk/harbour/source/rtl/errorsys.prg trunk/harbour/source/rtl/fserror.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[10729] trunk/harbour
Revision: 10729 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10729&view=rev Author: vouchcac Date: 2009-03-29 21:28:27 + (Sun, 29 Mar 2009) Log Message: --- 2009-03-29 09:03 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) + harbour/contrib/hbqt/doc + Added folder to receive auto-generated Q*.txt documentation files with PRG level functions with parameters and return value like: Qt_QWidget_setContentsMargins( pQWidget, nLeft, nTop, nRight, nBottom ) -> NIL + harbour/contrib/hbqt/gensource + Added folder to receive auto generated .cpp sources. The idea is to have freedom to generate sources and test them prior to committing to distribution folder. * harbour/contrib/hbqt/hbqt.h + Added more parameter and return macros. + harbour/contrib/hbqt/hbqt_utils.c + Added generic conversion routins to support parameters and return values. + harbour/contrib/hbqt/hbqt_qtreewidget.cpp + harbour/contrib/hbqt/hbqt_qtreewidgetitem.cpp * harbour/contrib/hbqt/hbqt_qtreeview.cpp * harbour/contrib/hbqt/generator/hbqtgen.prg ! Rearrangement of sequences in .qht files. Implemented project files with .qtp extension. Implemented auto generation of document files with .txt extension. USAGE: hbqtgen.exe @qt45.qtp will generate files as: . ../gensource/hbqt_Q*.cpp ../doc/Q*.txt + harbour/contrib/hbqt/generator/qt45.qtp + Added project file to generate sources and documenttaion for tested widgets. + harbour/contrib/hbqt/qth/QAbstractButton.qth + harbour/contrib/hbqt/qth/QAbstractItemView.qth + harbour/contrib/hbqt/qth/QAbstractPrintDialog.qth + harbour/contrib/hbqt/qth/QAbstractScrollArea.qth + harbour/contrib/hbqt/qth/QAbstractSlider.qth + harbour/contrib/hbqt/qth/QAbstractSpinBox.qth + harbour/contrib/hbqt/qth/QAction.qth + harbour/contrib/hbqt/qth/QApplication.qth + harbour/contrib/hbqt/qth/QBoxLayout.qth + harbour/contrib/hbqt/qth/QBrush.qth + harbour/contrib/hbqt/qth/QCalendarWidget.qth + harbour/contrib/hbqt/qth/QCheckBox.qth + harbour/contrib/hbqt/qth/QColor.qth + harbour/contrib/hbqt/qth/QColorDialog.qth + harbour/contrib/hbqt/qth/QComboBox.qth + harbour/contrib/hbqt/qth/QCommandLinkButton.qth + harbour/contrib/hbqt/qth/QCoreApplication.qth + harbour/contrib/hbqt/qth/QDateEdit.qth + harbour/contrib/hbqt/qth/QDateTimeEdit.qth + harbour/contrib/hbqt/qth/QDial.qth + harbour/contrib/hbqt/qth/QDialog.qth + harbour/contrib/hbqt/qth/QDoubleSpinBox.qth + harbour/contrib/hbqt/qth/QErrorMessage.qth + harbour/contrib/hbqt/qth/QFileDialog.qth + harbour/contrib/hbqt/qth/QFocusFrame.qth + harbour/contrib/hbqt/qth/QFont.qth + harbour/contrib/hbqt/qth/QFontComboBox.qth + harbour/contrib/hbqt/qth/QFontDialog.qth + harbour/contrib/hbqt/qth/QFormLayout.qth + harbour/contrib/hbqt/qth/QFrame.qth + harbour/contrib/hbqt/qth/QGroupBox.qth + harbour/contrib/hbqt/qth/QHBoxLayout.qth + harbour/contrib/hbqt/qth/QInputDialog.qth + harbour/contrib/hbqt/qth/QLabel.qth + harbour/contrib/hbqt/qth/QLayout.qth + harbour/contrib/hbqt/qth/QLayoutItem.qth + harbour/contrib/hbqt/qth/QLCDNumber.qth + harbour/contrib/hbqt/qth/QLineEdit.qth + harbour/contrib/hbqt/qth/QListView.qth + harbour/contrib/hbqt/qth/QMainWindow.qth + harbour/contrib/hbqt/qth/QMenu.qth + harbour/contrib/hbqt/qth/QMenuBar.qth + harbour/contrib/hbqt/qth/QMessageBox.qth + harbour/contrib/hbqt/qth/QObject.qth + harbour/contrib/hbqt/qth/QPageSetupDialog.qth + harbour/contrib/hbqt/qth/QPainter.qth + harbour/contrib/hbqt/qth/QPen.qth + harbour/contrib/hbqt/qth/QPrintDialog.qth + harbour/contrib/hbqt/qth/QPrintPreviewDialog.qth + harbour/contrib/hbqt/qth/QProgressBar.qth + harbour/contrib/hbqt/qth/QPushButton.qth + harbour/contrib/hbqt/qth/QRadioButton.qth + harbour/contrib/hbqt/qth/QScrollArea.qth + harbour/contrib/hbqt/qth/QScrollBar.qth + harbour/contrib/hbqt/qth/QSizeGrip.qth + harbour/contrib/hbqt/qth/QSlider.qth + harbour/contrib/hbqt/qth/QSpinBox.qth + harbour/contrib/hbqt/qth/QSplitter.qth + harbour/contrib/hbqt/qth/QTabBar.qth + harbour/contrib/hbqt/qth/QTableView.qth + harbour/contrib/hbqt/qth/QTableWidget.qth + harbour/contrib/hbqt/qth/QTableWidgetItem.qth + harbour/contrib/hbqt/qth/QTabWidget.qth + harbour/contrib/hbqt/qth/QTextEdit.qth + harbour/contrib/hbqt/qth/QTimeEdit.qth + harbour/contrib/hbqt/qth/QToolBar.qth + harbour/contrib/hbqt/qth/QToolBox.qth + harbour/contrib/hbqt/qth/QToolButton.qth + harbour/contrib/hbqt/qth/QTreeView.qth + harbour/contrib/hbqt/qth/QTreeWidget.qth + harbour/contrib/hbqt/qth/QTreeWidgetItem.qth + harbour/contrib/hbqt/qth/QVBoxLayout.qth + harbour/contrib/hbqt/qth/QWidget.qth + Added or changed(4) base header input files to generate sources. ; TODO - Create for generated sources. - Generate Classes b
Re: [Harbour] SF.net SVN: harbour-project:[10728] trunk/harbour
Hi Viktor,
Il 29/03/2009 22.53, vszak...@users.sourceforge.net ha scritto:
2009-03-29 22:26 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* contrib/xhb/hbserv.c
! Disabled for poccce.
Now I get:
J:\cvs\harbourSVN_trunk\contrib\xhb>if not exist ..\..\lib\win\msvc\. md
..\..\lib\win\msvc
make[3]: Entering directory `J:/cvs/harbourSVN_trunk/contrib/xhb/win/msvc'
cl.exe -nologo -I. -I../../../../include -Gs -TP -W4 -wd4127 -Ot2b1
-EHs-c- -MT -DHB_LEGACY_OFF -DHB_FM_STATISTICS_OFF -DHB_FM_DLMT_ALLOC
-c ../../hbserv.c -Fohbserv.obj
hbserv.c
../../hbserv.c(67) : error C2017: escape sequence not valit
../../hbserv.c(68) : error C2059: syntax error: '('
../../hbserv.c(772) : error C2065: 'pHVMFuncService': identifier not
declared
make[3]: Leaving directory `J:/cvs/harbourSVN_trunk/contrib/xhb/win/msvc'
make[2]: Leaving directory `J:/cvs/harbourSVN_trunk/contrib/xhb'
make[1]: Leaving directory `J:/cvs/harbourSVN_trunk/contrib'
Offending line 67 is:
#if !defined( HB_OS_DOS ) && \
!defined( HB_OS_DARWIN_5 ) \ /* DOS and Darwin < 6.x can't compile
this module */
! ( defined(HB_OS_WIN_CE) && defined(__POCC__) )
but I also tried with:
#if !defined( HB_OS_DOS ) && \
!defined( HB_OS_DARWIN_5 ) && \ -
! ( defined(HB_OS_WIN_CE) && defined(__POCC__) )
but result is the same
Best regards,
Francesco
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[10730] trunk/harbour
Revision: 10730 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10730&view=rev Author: vszakats Date: 2009-03-29 21:46:48 + (Sun, 29 Mar 2009) Log Message: --- 2009-03-29 22:46 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * contrib/xhb/hbserv.c ! Fixed issues with prev commit. (Thanks Francesco) Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/xhb/hbserv.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[10729] trunk/harbour
On Sun, 29 Mar 2009, vouch...@users.sourceforge.net wrote: Hi, > ; REQUEST ( Przemek ) - Can you please provide a GTWVT.C like > skeleton .cpp which I could use as a base for GTQTC ? I'll try to make it in this week. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[10729] trunk/harbour
Thanks a lot. Przemyslaw Czerpak-2 wrote: > >> ; REQUEST ( Przemek ) - Can you please provide a GTWVT.C like >> skeleton .cpp which I could use as a base for GTQTC ? > > I'll try to make it in this week. > Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/SF.net-SVN%3A-harbour-project%3A-10729--trunk-harbour-tp22773020p22773898.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] SF.net SVN: harbour-project:[10730] trunk/harbour
Hi Viktor, Il 29/03/2009 23.46, vszak...@users.sourceforge.net ha scritto: 2009-03-29 22:46 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * contrib/xhb/hbserv.c ! Fixed issues with prev commit. (Thanks Francesco) it works again. Thank you. Best regards, Francesco ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[10724] trunk/harbour
Your results are near optimal. Can't understand what i'm doing wrong =( ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[10724] trunk/harbour
Hi Angel, Il 30/03/2009 1.35, Angel Pais ha scritto: Your results are near optimal. Can't understand what i'm doing wrong =( I will wait Przemek before, but I suspect that there is influence of some software and surely there is CPU that is different. Could you try using MSTSC instead of VNC ? Best regards, Francesco ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[10724] trunk/harbour
Angel, Il 30/03/2009 1.46, Francesco Saverio Giudice ha scritto: Hi Angel, Il 30/03/2009 1.35, Angel Pais ha scritto: Your results are near optimal. Can't understand what i'm doing wrong =( I will wait Przemek before, but I suspect that there is influence of some software and surely there is CPU that is different. Could you try using MSTSC instead of VNC ? If you will publish xbase speedtst last version I will try it also, but I have few minutes before go to bed. Best regards, Francesco ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[10724] trunk/harbour
Thank you Francesco It will be usefull to know if it's a hardwre thing. Here the full set of tests: http://amigo-software.com.uy/test/speedhb.zip Regards Angel Francesco Saverio Giudice escribió: Angel, Il 30/03/2009 1.46, Francesco Saverio Giudice ha scritto: Hi Angel, Il 30/03/2009 1.35, Angel Pais ha scritto: Your results are near optimal. Can't understand what i'm doing wrong =( I will wait Przemek before, but I suspect that there is influence of some software and surely there is CPU that is different. Could you try using MSTSC instead of VNC ? If you will publish xbase speedtst last version I will try it also, but I have few minutes before go to bed. Best regards, Francesco ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[10724]
Angel Pais wrote: > Performance went to the sky ! > Scalability not so much... : > 03/29/09 17:58:22 Windows Server 2003 / XP x64 5.2.3790 > Harbour 1.1.0dev (Rev. 10726) (MT)+ Microsoft Visual C++ 14.0.24999 (32-bit) It looks like Windows 64-bit version and 32-bit executable. Can it effect the results? Chen. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
