List Info

Thread: Re: PATCH: SBU method change and bc removal.




Re: PATCH: SBU method change and bc removal.
user name
2007-05-24 08:27:48
On 5/24/07, Ag. D. Hatzimanikas <a.hatzimgmail.com> wrote:
> On Thu, May 24, at 10:47 Ag. D. Hatzimanikas wrote:
> > Please review it carefully (especially the
common/libs/func_validate_configs.sh)
>
> Correction: I was talking about
common/libs/func_wrt_Makefile of course.

One slightly bad thing happening there is that the build
commands used
to be run in a dedicated subshell ( ). With that, any
variables set
wouldn't leak to the parent process. Wait. That doesn't
matter since
make is running all commands in a their own dedicated shell
anyway.
Nevermind.

One other thing to think about is that we lose resolution
when we just
use whole seconds. But, that can be recovered if we use the
%N
modifier from date.

$ date +%s.%N
1180012692.545891184
$ start=`date +%s.%N`
$ ...
$ end=`date +%s.%N`
$ perl -e "printf "Time: %.3fn", ($end -
$start)"
Time: 24.432

But, the same thing could be done with time and a proper
TIMEFORMAT
variable. So, I think that the using perl instead of bc is a
win.
Using perl instead of time doesn't really gain anything,
though. When
I'd originally written that, it was because we were trying
to figure
out how to use dash, which doesn't have a time builtin. But,
just
forcing bash makes things easier.

--
Dan
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

Re: PATCH: SBU method change and bc removal.
country flaguser name
Greece
2007-05-24 10:01:52
On Thu, May 24, at 06:27 Dan Nicholson wrote:
> 
> One slightly bad thing happening there is that the
build commands used
> to be run in a dedicated subshell ( ). With that, any
variables set
> wouldn't leak to the parent process.

Funny, I was wandering about the same thing after I went out
and thinking
the implementation and I didn't knew the answer.

> Wait. That doesn't matter since make is running all
commands in a their
> own dedicated shell anyway.

So, it's not possible to store in a variable the
abstraction:
$end - $start
and take the total seconds of the build while we are doing
the
calculations, can't we?
That's why I had to write it in the log file first.

> One other thing to think about is that we lose
resolution when we just
> use whole seconds. But, that can be recovered if we use
the %N
> modifier from date.

Does really matters? We are talking about nanoseconds,
anyway it's not
that difficult if you would like to do that.
The difficult thing these is to win the Spurs and Duncan
these days. 

> But, the same thing could be done with time and a
proper TIMEFORMAT
> variable. So, I think that the using perl instead of bc
is a win.
> Using perl instead of time doesn't really gain
anything, though.
> I'd originally written that, it was because we were
trying to figure
> out how to use dash, which doesn't have a time builtin.
But, just
> forcing bash makes things easier.

This approach is shell agnostic, doesn't depends in Bash
internal variables
like time and so on, and so could be adopted by other shells
which is my 
desire also.
The gain in time is negligible. I've finished one build now
with this method,
and after a check it seems that it takes the same time.
Actually it's
that close, see:

				[gcc-pass1]
Patched Jhalfs : Build time is:	26 minutes and 2 seconds
Un-patched     : Build time is:	26 minutes and 35 seconds
or for	[glibc] is exactly the same.
Build time is:	16 minutes and 27 seconds
Build time is:	16 minutes and 27 seconds
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )