RE: Bug/limitation in 'time' (kernel setings?)...

ake. Either way, the consistent and pervasive conclusion is that time's CPU consumption results are significantly understated when multiple processes are involved. It would be nice to have that acknowledged in the documentation. If not, well, that's why I have a blog. -Original Message- F

Re: Bug/limitation in 'time' (kernel setings?)...

1) Why not use your 'null' program, which in your blog, you state makes little difference. 2) Better, why not use the simple 'fork'/exit' which doesn't call a separate program; (that's one reason for switching to perl or better, would be C; Note the perl prog: #!/usr/bin/perl die "need count" u

RE: Bug/limitation in 'time' (kernel setings?)...

upported by significant evidence. FWIW. -Original Message- From: Bruce Dawson [mailto:brucedaw...@cygnus-software.com] Sent: Wednesday, March 20, 2013 7:44 AM To: 'Linda Walsh' Cc: 'bug-bash' Subject: RE: Bug/limitation in 'time' (kernel setings?)... Not

RE: Bug/limitation in 'time' (kernel setings?)...

2013 1:12 AM To: Bruce Dawson Cc: bug-bash Subject: Re: Bug/limitation in 'time' (kernel setings?)... Bruce Dawson wrote: > The reply below is way too long, but oh well. > > The summary is: > I am 100% certain that my ExprCount() loop is CPU bound. Your stats cl

Re: Bug/limitation in 'time' (kernel setings?)...

Bruce Dawson wrote: > The reply below is way too long, but oh well. > > The summary is: > I am 100% certain that my ExprCount() loop is CPU bound. Your stats claim 530 iterations/second when spawning expr. That's ~2ms/process create. In an article from 14 years ago on a 200Mhz Pen

RE: Bug/limitation in 'time' (kernel setings?)...

te.. you said your loop took 2 seconds on your 3.2GHz sys. Yes, but that was then my system was running at 1.1 GHz. When my system ramps up to its full speed then the 1,000 iterations are done in less than a second. Our systems are quite consistent there. -Original Message- From: Linda Wa

Re: Bug/limitation in 'time' (kernel setings?)...

Linda Walsh wrote: > > Bruce Dawson wrote: >> How many CPUs do you have? 20% usage doesn't mean anything without knowing >> that. On a five-core system 20% usage would imply one full core. --- Another tool to check out if you have it is 'qps'... it can show the time slice/schedule interval ... I

Re: Bug/limitation in 'time' (kernel setings?)...

Bruce Dawson wrote: > How many CPUs do you have? 20% usage doesn't mean anything without knowing > that. On a five-core system 20% usage would imply one full core. --- If you look at the example that shows no process spawning overhead, it shows 100% cpu usage. 100%=1CPU, regardless of co

RE: Bug/limitation in 'time' (kernel setings?)...

s problematic for determining CPU usage. I'm not sure what its limitations are. -Original Message- From: Linda Walsh [mailto:b...@tlinx.org] Sent: Tuesday, March 19, 2013 9:10 AM To: Bruce Dawson; bug-bash Subject: Re: Bug/limitation in 'time' (kernel setings?)... Bruce Dawson

Re: Bug/limitation in 'time' (kernel setings?)...

Bruce Dawson wrote: > Hmmm -- again, that doesn't match what I see. bash is suspended while it > waits for expr to run, and the instant that expr completes bash runs again. > This can be seen in the profiler screenshot. The CPU is busy at all times, > and always busy on exactly one process. ---

RE: Bug/limitation in 'time' (kernel setings?)...

ailto:b...@tlinx.org] Sent: Tuesday, March 19, 2013 8:19 AM To: Bruce Dawson Cc: 'Pierre Gaston'; bug-bash@gnu.org; b...@packages.debian.org Subject: Re: Bug/limitation in 'time' (kernel setings?)... I think you misunderstand...what Pierre is saying -- your process is scheduled

Re: Bug/limitation in 'time' (kernel setings?)...

I think you misunderstand...what Pierre is saying -- your process is scheduled out to give others a *chance* to run and the scheduler isn't called often enough to roll you back in immediately when it finds out that no one else needs their time ticks... That's why I mentioned all of the scheduling

RE: Bug/limitation in 'time' (kernel setings?)...

@gmail.com] Sent: Tuesday, March 19, 2013 2:00 AM To: Bruce Dawson Cc: bug-bash@gnu.org; b...@packages.debian.org Subject: Re: Bug/limitation in 'time' (kernel setings?)... On Tue, Mar 19, 2013 at 5:03 AM, Bruce Dawson wrote: > I'll give those a try. > > BTW, I just posted the

Re: Bug/limitation in 'time' (kernel setings?)...

On Tue, Mar 19, 2013 at 5:03 AM, Bruce Dawson wrote: > I'll give those a try. > > BTW, I just posted the blog post to share what I'd found. You can see it > here: > > http://randomascii.wordpress.com/2013/03/18/counting-to-ten-on-linux/ > > I hope it's accurate, and I do think it would be worth me

RE: Bug/limitation in 'time' (kernel setings?)...

7;time' and the bash 'time' internal command. -Original Message- From: Linda Walsh [mailto:b...@tlinx.org] Sent: Monday, March 18, 2013 7:15 PM To: Bruce Dawson Cc: bug-bash@gnu.org; b...@packages.debian.org Subject: Re: Bug/limitation in 'time' (kernel seting

Re: Bug/limitation in 'time' (kernel setings?)...

Bruce Dawson wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i686 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='$ > uname output: Linux Ubuntu1m 3.2.0-35-generic-p

Re: Bug/limitation in 'time'

Chris Down wrote: > On 2013-03-18 00:46, Linda Walsh wrote: >> Bruce Dawson wrote: >>> Chris Down pointed that out. My loop now looks like this -- portable (I >>> believe) and fast: >>> >>> BashCount() { >>> for (( i = $1 ; i > 0 ; i-- )); do >>> : >>> done >>> echo Just did $

Re: Bug/limitation in 'time'

On 2013-03-18 00:46, Linda Walsh wrote: > Bruce Dawson wrote: > > Chris Down pointed that out. My loop now looks like this -- portable (I > > believe) and fast: > > > > BashCount() { > > for (( i = $1 ; i > 0 ; i-- )); do > > : > > done > > echo Just did $1 iterations using bash

Re: Bug/limitation in 'time'

Bruce Dawson wrote: > Chris Down pointed that out. My loop now looks like this -- portable (I > believe) and fast: > > BashCount() { > for (( i = $1 ; i > 0 ; i-- )); do > : > done > echo Just did $1 iterations using bash math > } To do the above, you'd want to pre-init

Re: Bug/limitation in 'time'

-bug-bash, +help-bash Bruce Dawson wrote: > Chris Down pointed that out. My loop now looks like this -- portable (I > believe) and fast: > > BashCount() { > for (( i = $1 ; i > 0 ; i-- )); do Not actually portable to non ksh-based shells. See for hints. Hope

RE: Bug/limitation in 'time'

On Sun, 17 Mar 2013, Bruce Dawson wrote: Chris Down pointed that out. My loop now looks like this -- portable (I believe) and fast: BashCount() { for (( i = $1 ; i > 0 ; i-- )); do No, that is not portable. The only portable use of (( ... )) is $(( ... )) -- Chris F.A. Johnson, <

RE: Bug/limitation in 'time'

day, March 17, 2013 8:36 PM To: Bruce Dawson Cc: 'Chris Down'; bug-bash@gnu.org; b...@packages.debian.org Subject: Re: Bug/limitation in 'time' Bruce Dawson wrote: > Yep, we've changed our loops to use roughly that syntax. Unfortunately > a lot of online resources r

Re: Bug/limitation in 'time'

Bruce Dawson wrote: > Yep, we've changed our loops to use roughly that syntax. Unfortunately a lot > of online resources recommend the $(expr) technique. My understanding is > that using $(expr) is more portable, because i-- is bash specific, but I > don't really know. but $((i-=1)) isn't Bash s

Re: Bug/limitation in 'time'

On Sunday, March 17, 2013 01:09:47 AM William Park wrote: > On Sat, Mar 16, 2013 at 10:15:50PM -0400, Chris F.A. Johnson wrote: > > On Sun, 17 Mar 2013, Chris Down wrote: > > > ExprCount() { > > > for (( i = $1 ; i > 0 ; i-- )); do > > > : > > > done > > > echo "$1 ite

Re: Bug/limitation in 'time'

On Sun, Mar 17, 2013 at 9:07 PM, Bob Proulx wrote: > Bruce Dawson wrote: >> The man page is clear that it is displaying the results of wait3(). > > Man page for time? You mean the time section of the man page for > bash. no > If you are looking at the time man page then you are looking at > the

Re: Bug/limitation in 'time'

Bruce Dawson wrote: > The man page is clear that it is displaying the results of wait3(). Man page for time? You mean the time section of the man page for bash. If you are looking at the time man page then you are looking at the standalone /usr/bin/time command and not the bash builtin time comm

Re: Bug/limitation in 'time'

On Sun, Mar 17, 2013 at 5:58 PM, Bruce Dawson wrote: > The man page is clear that it is displaying the results of wait3(). However > it doesn't mention that this means that sub-process startup time is not > accounted for. That's what I feel should be clarified. Otherwise a CPU bound > task may app

Re: Bug/limitation in 'time'

This version is actually slightly faster... And the sys time goes down very close to zero. Now, what were you actually looking to test?? My version might be utterly irrelevant. function BashCount() { i=$1 while (( i-- )) ; do true done echo Just

RE: Bug/limitation in 'time'

propriate to document this. Anyway, if the docs can be updated I think that would be great. If not, no worries. -Original Message- From: Pierre Gaston [mailto:pierre.gas...@gmail.com] Sent: Saturday, March 16, 2013 11:31 PM To: Bruce Dawson Cc: bug-bash@gnu.org Subject: Re: Bug/limitation i

Re: Bug/limitation in 'time'

On Sun, Mar 17, 2013 at 4:33 AM, Bruce Dawson wrote: > Thanks -- good to know that there is a fast and POSIX compliant method of > doing this. I should have included my optimized counting loop -- it's what > we switched to when we realized that $(expr) was a problem. Here it is now: > > # This cod

Re: Bug/limitation in 'time'

On Sun, 17 Mar 2013, William Park wrote: On Sat, Mar 16, 2013 at 10:15:50PM -0400, Chris F.A. Johnson wrote: On Sun, 17 Mar 2013, Chris Down wrote: ExprCount() { for (( i = $1 ; i > 0 ; i-- )); do : done echo "$1 iterations" } Or, in a POSIX-compliant manne

Re: Bug/limitation in 'time'

On 2013-03-17 01:09, William Park wrote: > Are you saying that > > for (( ; ; )) > > is not POSIX? `((' is not POSIX. pgpstbEnn7hm4.pgp Description: PGP signature

Re: Bug/limitation in 'time'

On Sat, Mar 16, 2013 at 10:15:50PM -0400, Chris F.A. Johnson wrote: > On Sun, 17 Mar 2013, Chris Down wrote: > > ExprCount() { > > for (( i = $1 ; i > 0 ; i-- )); do > > : > > done > > echo "$1 iterations" > > } > >Or, in a POSIX-compliant manner: > > ExprCount

Re: Bug/limitation in 'time'

On Sun, 17 Mar 2013, Chris Down wrote: Hi Bruce, On 2013-03-16 17:41, Bruce Dawson wrote: I think it's important because when I hit this problem (using $(expr) for looping in shell scripts is slow) I initially assumed that my task was not CPU bound, because that is what 'time' told me. This th

RE: Bug/limitation in 'time'

[mailto:ch...@chrisdown.name] Sent: Saturday, March 16, 2013 6:58 PM To: Bruce Dawson Cc: bug-bash@gnu.org; b...@packages.debian.org Subject: Re: Bug/limitation in 'time' Hi Bruce, On 2013-03-16 17:41, Bruce Dawson wrote: > I think it's important because when I hit this problem (

Re: Bug/limitation in 'time'

On 2013-03-16 19:18, Bruce Dawson wrote: > Yep, we've changed our loops to use roughly that syntax. Unfortunately a lot > of online resources recommend the $(expr) technique. Unfortunately most online resources on bash are terrible. The only ones I can recommend outside of the official documentati

Re: Bug/limitation in 'time'

On 2013-03-16 19:33, Bruce Dawson wrote: > Thanks -- good to know that there is a fast and POSIX compliant method of > doing this. I should have included my optimized counting loop -- it's what > we switched to when we realized that $(expr) was a problem. Here it is now: > > # This code performs qu

RE: Bug/limitation in 'time'

org Cc: Chris Down; Bruce Dawson Subject: Re: Bug/limitation in 'time' On Sun, 17 Mar 2013, Chris Down wrote: > Hi Bruce, > > On 2013-03-16 17:41, Bruce Dawson wrote: >> I think it's important because when I hit this problem (using $(expr) >> for looping in shell

Re: Bug/limitation in 'time'

Hi Bruce, On 2013-03-16 17:41, Bruce Dawson wrote: > I think it's important because when I hit this problem (using $(expr) for > looping in shell scripts is slow) I initially assumed that my task was not > CPU bound, because that is what 'time' told me. This then led me down the > wrong path in my