Maurilio Longo wrote:
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.
Hi,
thank You. That helps in my case also. -j4, -j5, -j99 do nothing, but -j
makes build harbour more than twice fast
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 optimizatio
>> 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
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 t
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 -j is passed
as GNU make parameter then it creates upto processes and each
of them is used
On Mon, 29 Mar 2010, Mindaugas Kavaliauskas wrote:
Hi,
> in ChangeLog I found some -j option for parallel compile jobs.
> How can it use it?
> I'm trying:
> win-make.exe -j4
> but I see no compile speed improvement.
This option enables simultaneous compilation of different files.
It means that
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 lit
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 -O
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 consumi
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.
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 an
quot;
To: "Harbour Project Main Developer List."
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
> 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 compile
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. Dou
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, becau
> 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
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...
Regards,
Mindaug
17 matches
Mail list logo
