Re: [Harbour] mingw 4.5.0 benchmarks
Mindaugas, as I wrote earlier I did not see any difference as well unless i just call it with -j (without number), in this case I see both of my cores doing work. I'm using the dragon media flavor of mingw. Maurilio. Mindaugas Kavaliauskas wrote: You can also try to reduce the optimization level, i.e. you can use -Os in MinGW flags. It should reduce the compilation time and final binaries will be slower then the one created by BCC though still faster. I'm trying another approach :) Upgrading from Celeron to Core i5. It should help a little. :) Hi, in ChangeLog I found some -jn option for parallel compile jobs. How can it use it? I'm trying: win-make.exe -j4 but I see no compile speed improvement. Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw 4.5.0 benchmarks
You can also try to reduce the optimization level, i.e. you can use -Os in MinGW flags. It should reduce the compilation time and final binaries will be slower then the one created by BCC though still faster. I'm trying another approach :) Upgrading from Celeron to Core i5. It should help a little. :) Hi, in ChangeLog I found some -jn option for parallel compile jobs. How can it use it? I'm trying: win-make.exe -j4 but I see no compile speed improvement. Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw 4.5.0 benchmarks
Przemysław Czerpak wrote: This option enables simultaneous compilation of different files. It means that it will not change the compilation of single file at all but when many files have to be compiled and -jn is passed as GNU make parameter then it creates upto n processes and each of them is used to compile different files. So the total compilation time of is greatly reduced on multi CPU machine. Personally I'm using -j4 or -j5 on my 3 CPU machine and it reduces total Harbour compilation time about 3 times. Hi, I'm trying to compile the whole Harbour on Core i5 (2 cores + hyper-threading, so, 4 virtual CPU are visible to the system). But I see no speed improvement of -j4 using: win-make.exe -j4 Is this correct way to pass -j4 option? I though, that maybe I need to pass in a different way: set HB_MAKE_OPTIONS=-j4 or something like that, to make -j work Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw 4.5.0 benchmarks
On Mon, 29 Mar 2010, Mindaugas Kavaliauskas wrote: Hi, I'm trying to compile the whole Harbour on Core i5 (2 cores + hyper-threading, so, 4 virtual CPU are visible to the system). But I see no speed improvement of -j4 using: win-make.exe -j4 Is this correct way to pass -j4 option? I though, that maybe I need For me it's enough. I'm using: make -j5 I even tested MinGW cross build and it works very nice but maybe this win-make.exe does not support it. to pass in a different way: set HB_MAKE_OPTIONS=-j4 or something like that, to make -j work I do not know about it. Maybe Viktor can help. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw 4.5.0 benchmarks
I'm trying to compile the whole Harbour on Core i5 (2 cores + hyper-threading, so, 4 virtual CPU are visible to the system). But I see no speed improvement of -j4 using: win-make.exe -j4 Is this correct way to pass -j4 option? I though, that maybe I need For me it's enough. I'm using: make -j5 I even tested MinGW cross build and it works very nice but maybe this win-make.exe does not support it. It should support it. It's standard 3.81 build. to pass in a different way: set HB_MAKE_OPTIONS=-j4 or something like that, to make -j work I do not know about it. Maybe Viktor can help. No such trick is needed. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw 4.5.0 benchmarks
Hi, Przemysław Czerpak wrote: It's important only if you have to often recompile very big C files which can be hardly optimized. It happens if you develop and compile Harbour itself, but not the final application only. You can also try to reduce the optimization level, i.e. you can use -Os in MinGW flags. It should reduce the compilation time and final binaries will be slower then the one created by BCC though still faster. I'm trying another approach :) Upgrading from Celeron to Core i5. It should help a little. :) Though, many new features of Win 7 is annoying. Trying to switch of everything. Does anyone know how to remove Favorites and Libraries entries form navigation panel of Explorer. I also want to remove this Organize/Include in library/Share with/New folder toolbar line. Any suggestions? Classic style start menu seems to be gone forever... Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw 4.5.0 benchmarks
On Fri, 19 Mar 2010, Mindaugas Kavaliauskas wrote: Hi, I've included BCC55 for comparison. It's running at half the overall speed compared to 4.5 64-bit. Ec... I'm still using BCC, because... it compiles f.e. \external\sqlite3 in 2.74 s, and MGW compiles it in 3 minutes 3.25 s, i.e. 67 times slower... It's important only if you have to often recompile very big C files which can be hardly optimized. So you can use BCC when you are working on such files and MinGW to create final binaries. You can also try to reduce the optimization level, i.e. you can use -Os in MinGW flags. It should reduce the compilation time and final binaries will be slower then the one created by BCC though still faster. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw 4.5.0 benchmarks
On Fri, 19 Mar 2010, Maurilio Longo wrote: Hi, for real code, doing I/O on a network share, the difference could be lower, though. Network IO operations are extremely expensive so they will consume most of time anyhow in local IO operations are not such significant and there are time consuming operations which can be done locally, i.e. reindexing. Please also note that usually *nix applications are executed remotely on the server side only so the execution speed is not reduced by network overhead at all. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] mingw 4.5.0 benchmarks
Hi All,
In summary with 4.5 there is a 7-8% speed increase
compared to 4.4.4 in 64-bit mode and C++ doesn't
give any speed advantage here. Binary sizes are
similar, sometimes a big larger sometimes a bit
smaller.
I've included BCC55 for comparison. It's running
at half the overall speed compared to 4.5 64-bit.
---
2010.03.19 Windows 7 6.1.7600
THREADS: 0
N_LOOPS: 100
[1] Harbour 2.1.0dev (Rev. 14188) MinGW GNU C 4.5 (64-bit) x86-64
[2] Harbour 2.1.0dev (Rev. 14189) MinGW GNU C++ 4.5 (64-bit) x86-64
[3] Harbour 2.1.0dev (Rev. 14130) MinGW GNU C 4.4.4 (64-bit) x86-64
[4] Harbour 2.1.0dev (Rev. 14178) Borland C++ 5.5.1 (32-bit) x86
[1][2]
[3][4]
[ T000: empty loop overhead ]...0.02 ..0.02
..0.02 ..0.05
==
== ==
[ T001: x := L_C ]..0.02 ..0.02
..0.03 ..0.02
[ T002: x := L_N ]..0.00 ..0.02
..0.02 ..0.02
[ T003: x := L_D ]..0.00 ..0.00
..0.00 ..0.02
[ T004: x := S_C ]..0.02 ..0.03
..0.03 ..0.05
[ T005: x := S_N ]..0.03 ..0.02
..0.05 ..0.03
[ T006: x := S_D ]..0.02 ..0.03
..0.02 ..0.03
[ T007: x := M-M_C ]...0.02 ..0.02
..0.03 ..0.05
[ T008: x := M-M_N ]...0.03 ..0.03
..0.05 ..0.05
[ T009: x := M-M_D ]...0.02 ..0.02
..0.03 ..0.03
[ T010: x := M-P_C ]...0.03 ..0.03
..0.03 ..0.05
[ T011: x := M-P_N ]...0.03 ..0.02
..0.03 ..0.03
[ T012: x := M-P_D ]...0.02 ..0.02
..0.03 ..0.05
[ T013: x := F_C ]..0.09 ..0.09
..0.11 ..0.14
[ T014: x := F_N ]..0.14 ..0.11
..0.11 ..0.17
[ T015: x := F_D ]..0.06 ..0.05
..0.06 ..0.09
[ T016: x := o:Args ]...0.08 ..0.08
..0.09 ..0.14
[ T017: x := o[2] ].0.03 ..0.05
..0.05 ..0.09
[ T018: round( i / 1000, 2 ) ]..0.09 ..0.11
..0.11 ..0.17
[ T019: str( i / 1000 ) ]...0.27 ..0.22
..0.23 ..0.55
[ T020: val( s ) ]..0.11 ..0.11
..0.11 ..0.22
[ T021: val( a [ i % 16 + 1 ] ) ]...0.17 ..0.16
..0.19 ..0.38
[ T022: dtos( d - i % 1 ) ].0.16 ..0.17
..0.19 ..0.33
[ T023: eval( { || i % 16 } ) ].0.20 ..0.22
..0.23 ..0.30
[ T024: eval( bc := { || i % 16 } ) ]...0.11 ..0.14
..0.13 ..0.20
[ T025: eval( { |x| x % 16 }, i ) ].0.16 ..0.17
..0.17 ..0.27
[ T026: eval( bc := { |x| x % 16 }, i ) ]...0.11 ..0.13
..0.14 ..0.22
[ T027: eval( { |x| f1( x ) }, i ) ]0.22 ..0.20
..0.23 ..0.33
[ T028: eval( bc := { |x| f1( x ) }, i ) ]..0.16 ..0.14
..0.19 ..0.28
[ T029: eval( bc := ({ |x| f1( x ) }), i ) ].0.17 ..0.19
..0.19 ..0.28
[ T030: x := ( f1( + str(i) + ) ) ]1.34 ..1.41
..1.33 ..2.42
[ T031: bc := ( {|x|f1(x)} ), eval( bc, i ) ]1.58 ..1.66
..1.55 ..3.08
[ T032: x := valtype( x ) + valtype( i ) ].0.17 ..0.17
..0.22 ..0.34
[ T033: x := strzero( i % 100, 2 ) $ a[ i % 16 + 1 ] ]..0.30 ..0.30
..0.33 ..0.64
[ T034: x := a[ i % 16 + 1 ] == s ].0.11 ..0.11
..0.13 ..0.23
[ T035: x := a[ i % 16 + 1 ] = s ]..0.13 ..0.11
..0.13 ..0.27
[ T036: x := a[ i % 16 + 1 ] = s ].0.13 ..0.13
..0.14 ..0.27
[ T037: x := a[ i % 16 + 1 ] = s ].0.13 ..0.13
..0.14 ..0.27
[ T038: x := a[ i % 16 + 1 ] s ]..0.13 ..0.13
..0.14 ..0.27
[ T039: x := a[ i % 16 + 1 ] s ]..0.13 ..0.11
..0.14 ..0.27
[ T040: ascan( a, i % 16 ) ]0.16 ..0.16
..0.16 ..0.25
[ T041: ascan( a, { |x| x == i % 16 } ) ]...1.23 ..1.28
..1.41 ..2.34
[ T042: iif( i%1000==0, a:={}, ) , aadd(a,{i,1,.T.,s,s2,a2 ]0.36 ..0.36
..0.44 ..0.72
[ T043: x := a ]0.02 ..0.02
..0.02 ..0.05
[ T044: x := {} ]...0.05 ..0.05
..0.06 ..0.09
[ T045: f0() ]..0.03 ..0.03
..0.05 ..0.03
Re: [Harbour] mingw 4.5.0 benchmarks
Viktor Szakáts wrote: I've included BCC55 for comparison. It's running at half the overall speed compared to 4.5 64-bit. Ec... I'm still using BCC, because... it compiles f.e. \external\sqlite3 in 2.74 s, and MGW compiles it in 3 minutes 3.25 s, i.e. 67 times slower... Yes, it's good for draft builds. Though at least for live builds used by real users IMO it's worth to take the pain of a longer build to offer a faster working application. It's a one time overhead on developer's side and and permanent and noticeable gain on the users' side. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw 4.5.0 benchmarks
Viktor, for real code, doing I/O on a network share, the difference could be lower, though. Maurilio. Viktor Szakáts wrote: Viktor Szakáts wrote: I've included BCC55 for comparison. It's running at half the overall speed compared to 4.5 64-bit. Ec... I'm still using BCC, because... it compiles f.e. \external\sqlite3 in 2.74 s, and MGW compiles it in 3 minutes 3.25 s, i.e. 67 times slower... Yes, it's good for draft builds. Though at least for live builds used by real users IMO it's worth to take the pain of a longer build to offer a faster working application. It's a one time overhead on developer's side and and permanent and noticeable gain on the users' side. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw 4.5.0 benchmarks
Hi Maurilio, Viktor, for real code, doing I/O on a network share, the difference could be lower, though. Yes, of course speedtst is not the one-and-only ultimate bench, though it still shows big difference in a lot of important places, f.e. a table upgrade or reindexing on server. Double the speed is big difference. BTW I can feel much smaller difference even with procedural CUI app, and this is pbly much noticeable in OOP and/or GUI apps where much more .prg code is pumped trough the HVM/CPU. Fast execution can most probably make these apps to behave snappier and thus user experience better. It's IMO also important to actually exploit the possibilities of hardware and not waste the cycles / wattage / users' time, nerves / etc. BTW, it'd be interesting exercise to see how faster gcc/mingw gets with lower optimization levels and how execution speed drops. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw 4.5.0 benchmarks
Though at least for live builds used by real users IMO it's worth to take the pain of a longer build to offer a faster working application. It's a one time overhead on developer's side and and permanent and noticeable gain on the users' side. No problem for a lng one-time compiler build but I believe that also prg compilation is slower... hbmk2 incremental helps a lot but it is anyway a longer edit-compile-debug cycle ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw 4.5.0 benchmarks
Hello Francesco, Just to mention: Did you try the hbmk2 -jobs=n option. This option starts n compilaton threads (multiprocess plataforms only). It works very well for me and reduces the compilation time. Qatan - Original Message - From: francesco perillo fperi...@gmail.com To: Harbour Project Main Developer List. harbour@harbour-project.org Sent: Friday, March 19, 2010 2:20 PM Subject: Re: [Harbour] mingw 4.5.0 benchmarks Though at least for live builds used by real users IMO it's worth to take the pain of a longer build to offer a faster working application. It's a one time overhead on developer's side and and permanent and noticeable gain on the users' side. No problem for a lng one-time compiler build but I believe that also prg compilation is slower... hbmk2 incremental helps a lot but it is anyway a longer edit-compile-debug cycle ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw 4.5.0 benchmarks
Compilation process is obviously slower than for a non-optimizing compiler, also for .prg since it's also compiled by C compiler. Here it should be noted that plain -gc2 built .c files can just be compiled using any C compiler option (ie. without optimization), since it cannot be optimized anyway. [ maybe such optimization can be added to hbmk2, to turn off C compiler optimization in this scenario. But it can be done manually as well, for those who use default = -gc2 options. ] [ In -gc3 mode the situation is different, but -gc3 isn't very good for app level code in general. ] Anyway for interim / local / developer's build it's fine to use C compiler without optimizations (and maybe with enabled debugging option), and for final build use the slow, but optimal settings. That's the whole idea of release vs debug builds. With Harbour/hbmk2 it's quite easy to switch compilers, or toggle optimizations. Brgds, Viktor On 2010 Mar 19, at 18:20, francesco perillo wrote: Though at least for live builds used by real users IMO it's worth to take the pain of a longer build to offer a faster working application. It's a one time overhead on developer's side and and permanent and noticeable gain on the users' side. No problem for a lng one-time compiler build but I believe that also prg compilation is slower... hbmk2 incremental helps a lot but it is anyway a longer edit-compile-debug cycle ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
