Bill Hoffman wrote:
Filipe Sousa wrote:
Is that 6 minutes?? The test is to run make in a tree that has
everything already built. We not trying to measure the speed of the
compiler but rather the speed of make checking the depend information.
Oops!
There you go
*cmake version 2.7-20080325
Filipe Sousa wrote:
Alan W. Irwin wrote:
On 2008-03-25 14:28-0400 Bill Hoffman wrote:
--- build all of paraview with nothing needing a build:
2.6
make 15.21s user 5.55s system 74% cpu 28.049 total
make 15.44s user 5.35s system 98% cpu 21.073 total
make -j5
real6m13.039s
user20m42
Alan W. Irwin wrote:
On 2008-03-25 14:28-0400 Bill Hoffman wrote:
--- build all of paraview with nothing needing a build:
2.6
make 15.21s user 5.55s system 74% cpu 28.049 total
make 15.44s user 5.35s system 98% cpu 21.073 total
make -j5
real6m13.039s
user20m42.308s
sys 2m43.99
Alan W. Irwin wrote:
The sum of user+system times is the most relevant number since that will be
the actual time the user will have to wait if the system is otherwise idle.
Thus, I have calculated that number above (which also shows the good
consistency of your repeated measurements). From thos
On Tuesday 25 March 2008, Alan W. Irwin wrote:
> On 2008-03-25 14:28-0400 Bill Hoffman wrote:
...
> Thanks, Bill, for running these paraview latency tests. My view is they
> should decide the matter unless KDE or some other project with similar or
> larger latency to paraview disagrees with the pa
On 2008-03-25 14:28-0400 Bill Hoffman wrote:
--- build all of paraview with nothing needing a build:
2.6
make 15.21s user 5.55s system 74% cpu 28.049 total
make 15.44s user 5.35s system 98% cpu 21.073 total
user+system = 20.76s and 20.79s for the two runs.
2.4
make 14.40s user 5.09s syst
Bill Hoffman wrote:
Clinton Stimpson wrote:
I was getting better numbers than that with parallel builds (is that
expected?).
A plain make was a touch faster, and make pqCore was almost 2x as fast.
Yes, parallel builds should be faster, as the checks for some targets
can be done in parallel
Clinton Stimpson wrote:
I was getting better numbers than that with parallel builds (is that
expected?).
A plain make was a touch faster, and make pqCore was almost 2x as fast.
Yes, parallel builds should be faster, as the checks for some targets
can be done in parallel. I was just trying
Bill Hoffman wrote:
Bill Hoffman wrote:
Sure, it will take some time to do this, as a build of paraview can
take some time, and I will have to do it twice. However, with the
single target in ParaView case, I know when Brad made the change he
saw significant speed ups, but I do not have the
Bill Hoffman wrote:
Sure, it will take some time to do this, as a build of paraview can take
some time, and I will have to do it twice. However, with the single
target in ParaView case, I know when Brad made the change he saw
significant speed ups, but I do not have the numbers.
OK, so t
Alan W. Irwin wrote:
I have previously asked Alex to do the KDE case. Bill, would you be
willing
to measure latency for ParaView for cmake 2.4.8 and the present cvs version
of CMake?
Sure, it will take some time to do this, as a build of paraview can take
some time, and I will have to do
Hi Bill:
I just now tested (with the build on one of the PLplot C examples)
the assertion that specific targets will have less latency
with the new approach. Here are the results.
[EMAIL PROTECTED]> make x10c
[ 0%] Built target plhershey-unicode-gen
[ 0%] Built target plhershey-unicode.h_bui
OK, so for a small project like PLplot, where it does a make in 1 to 2
seconds if nothing needs to be done, this stuff really does does not
matter that much. Adding the phony targets may have actually made it
take longer as make would have to parse that much more stuff. As for
the new way cm
On 2008-03-24 10:33-0400 Bill Hoffman wrote:
OK, I talked with Brad, and found out the difference from 2.4.8 and CVS.
When make runs in a CMake project, the first thing it does is run cmake to
check the depend information. It looks for missing header files, and other
checks to see if CMake sh
On 2008-03-24 10:27-0400 Bill Hoffman wrote:
One more warning about adding your own -I flags... I think this will break
the dependency scanner of CMake, and the depends will be wrong if you do not
use include_directories.
Our use case is we have a directory where our many different device dr
OK, I talked with Brad, and found out the difference from 2.4.8 and CVS.
When make runs in a CMake project, the first thing it does is run
cmake to check the depend information. It looks for missing header
files, and other checks to see if CMake should re-run or not. In 2.4.8,
CMake would do
One more warning about adding your own -I flags... I think this will
break the dependency scanner of CMake, and the depends will be wrong if
you do not use include_directories.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman
Alan W. Irwin wrote:
Hi Bill:
Plplot now builds for the cvs version of CMake so I am finally in a
position
to continue this thread.
Here is the 2.4.8 latency for the current version of PLplot
[EMAIL PROTECTED]> time make >& /dev/null
real0m1.454s
user0m0.800s
sys 0m0.724s
By re
On 2008-03-18 10:06-0400 Bill Hoffman wrote:
Bill Hoffman wrote:
We used to have something that removed many implicit rules. I think that
got lost in some version of CMake, it is hard to test... I did find that
there is a command line option to gmake, -r that turns off implicit rules.
Alan W. Irwin wrote:
On 2008-03-20 12:50-0400 Bill Hoffman wrote:
Alan W. Irwin wrote:
On 2008-03-18 10:06-0400 Bill Hoffman wrote:
I played around with make -d and -p and found that the .SUFFIXES
rule that was supposed to be removing the implicit rules for gmake
was not working for everyth
On 2008-03-20 12:50-0400 Bill Hoffman wrote:
Alan W. Irwin wrote:
On 2008-03-18 10:06-0400 Bill Hoffman wrote:
I played around with make -d and -p and found that the .SUFFIXES rule
that was supposed to be removing the implicit rules for gmake was not
working for everything. SCCS and RCS we
Alan W. Irwin wrote:
On 2008-03-18 10:06-0400 Bill Hoffman wrote:
I played around with make -d and -p and found that the .SUFFIXES rule
that was supposed to be removing the implicit rules for gmake was not
working for everything. SCCS and RCS were being checked for a bunch
of stuff. Anywa
On 2008-03-18 10:06-0400 Bill Hoffman wrote:
I played around with make -d and -p and found that the .SUFFIXES rule that
was supposed to be removing the implicit rules for gmake was not working for
everything. SCCS and RCS were being checked for a bunch of stuff. Anyway,
try this and see if
Bill Hoffman wrote:
We used to have something that removed many implicit rules. I think
that got lost in some version of CMake, it is hard to test... I did
find that there is a command line option to gmake, -r that turns off
implicit rules. I am seeing a speed up with gmake -r. Would i
Alan W. Irwin wrote:
To summarize, the above quote from GNU make documentation shows they were
concerned about the latency of the "force" alternative to .PHONY. If you
have ever run GNU make in debug mode, there is a lot of stuff it goes
through to look for implicit rules that fit the target so
On 2008-03-17 21:22-0400 Bill Hoffman wrote:
Alan W. Irwin wrote:
The GNU make documentation states the following:
Since it knows that phony targets do not name actual files that
could be remade from other files, make skips the implicit rule search
for phony targets This is why de
Alan W. Irwin wrote:
The GNU make documentation states the following:
Since it knows that phony targets do not name actual files that
could be remade from other files, make skips the implicit rule search
for phony targets This is why declaring a
target phony is good for [make] pe
The GNU make documentation states the following:
Since it knows that phony targets do not name actual files that
could be remade from other files, make skips the implicit rule search
for phony targets This is why declaring a
target phony is good for [make] performance
Also,
28 matches
Mail list logo
