search for: 0outputs

...ded somewhere from 4 - 5 times more time than lame to encode a file. (text report from my script is appende later in this mail) DECODE SPEED: ------------- OK.. not speed.. CPU usage :-) on a K6-188 -> ogg123: 176.56user 1.44system 5:01.00elapsed 59%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (1229major+280minor)pagefaults 0swaps -> mpg123: 50.57user 3.50system 5:00.65elapsed 17%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (2396major+116minor)pagefaults 30swaps COMMENTS: ---------- For Alpha software Ogg/Vorbis is great. OGG size is comparable to MP3 size (will this improv...

...ded somewhere from 4 - 5 times more time than lame to encode a file. (text report from my script is appende later in this mail) DECODE SPEED: ------------- OK.. not speed.. CPU usage :-) on a K6-188 -> ogg123: 176.56user 1.44system 5:01.00elapsed 59%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (1229major+280minor)pagefaults 0swaps -> mpg123: 50.57user 3.50system 5:00.65elapsed 17%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (2396major+116minor)pagefaults 30swaps COMMENTS: ---------- For Alpha software Ogg/Vorbis is great. OGG size is comparable to MP3 size (will this improv...

...] test 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 llvm/dummy bash-4.1$ /usr/bin/time git log --no-color -z --pretty=raw --show-notes --parents --boundary HEAD -- dummy > /dev/null 198.37user 0.40system 3:18.67elapsed 100%CPU (0avgtext+0avgdata 696456maxresident)k 0inputs+0outputs (0major+175765minor)pagefaults 0swaps But also when examining older files, here are some tests using the monorepo: bash-4.1$ git clone https://github.com/llvm/llvm-project.git llvm-project bash-4.1$ cd llvm-project bash-4.1$ /usr/bin/time git log --no-color -z --pretty=raw --show-notes --parent...

...inker waits) it may be possible but, again, it only speaks > about the relative sizes of LLVM/Cray's compiler. Ok, here are some hard numbers for empty builds: LLVM empty build: /usr/bin/time make -j16 4.32user 2.47system 0:03.21elapsed 211%CPU (0avgtext+0avgdata 13376maxresident)k 0inputs+0outputs (0major+671804minor)pagefaults 0swaps Cray empty build: /usr/bin/time make dynamic-developer -j16 2.88user 1.06system 0:04.94elapsed 79%CPU (0avgtext+0avgdata 64208maxresident)k 0inputs+0outputs (0major+184605minor)pagefaults 0swaps The Cray empty build includes some really horrendous shell scrip...

Nico Weber <thakis at chromium.org> writes: > On Tue, Nov 1, 2011 at 3:09 PM, David A. Greene <greened at obbligato.org> wrote: >> Óscar Fuentes <ofv at wanadoo.es> writes: >> >>> Okay, we can get rid of recursive make. However, as pointed out >>> elsewhere, removing recursive make will not make a difference on the >>> LLVM build. What

On Tue, Nov 01, 2011 at 06:27:35PM -0500, David A. Greene wrote: > Here is actual data comparing an empty LLVM build done recursively (the > LLVM build) and non-recursively (the Cray build). > > See this? > > 0inputs+0outputs (0major+671804minor)pagefaults 0swaps > > vs. this? > > 0inputs+0outputs (0major+184605minor)pagefaults 0swaps > > That's I/O. Sorry to disappoint you, but no, this isn't I/O. You have just shown that a LLVM build touches more mmap'd pages. Joerg

...;, nothing more) 1. Making a new 3 GB (1024 x 3megabytes blocks) file with dd needs 10.18 sec wallclock time: taskset 1 time dd if=/dev/zero bs=3M count=1024 of=~backes/xxxxx 1024+0 records in 1024+0 records out 0.00user 10.02system 0:10.18elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+187minor)pagefaults 0swaps 2. Repeating the same for 3 times: taskset 1 time dd if=/dev/zero bs=3M count=1024 of=~backes/xxxxx 1024+0 records in 1024+0 records out 0.00user 11.88system 1:05.26elapsed 18%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+187minor)pagefaults 0s...

greened at obbligato.org (David A. Greene) writes: > Ok, here are some hard numbers for empty builds: > > LLVM empty build: > /usr/bin/time make -j16 > 4.32user 2.47system 0:03.21elapsed 211%CPU (0avgtext+0avgdata 13376maxresident)k > 0inputs+0outputs (0major+671804minor)pagefaults 0swaps So your 16-way machine takes 2.5 times more than my 4-way cheap desktop... > Cray empty build: > /usr/bin/time make dynamic-developer -j16 > 2.88user 1.06system 0:04.94elapsed 79%CPU (0avgtext+0avgdata 64208maxresident)k > 0inputs+0outputs (0major...

...sword: cd1_en_binary.iso rsync: error writing 16385 unbuffered bytes - exiting: Connection reset by peer rsync error: error in rsync protocol data stream (code 12) at io.c(463) Command exited with non-zero status 12 0.30user 0.50system 0:39.23elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (254major+648minor)pagefaults 0swaps if no -z, things go fine: $ time rsync -Pv --stats cd1_en_binary.iso mail.cheek.com::root/home/ericom Password: cd1_en_binary.iso 616431616 100% 190.94kB/s 0:52:32 rsync[8871] (sender) heap statistics: arena: 70552 (bytes from sbrk) ordbl...

I got used to rsync's -v --progress option so much that I used it instead of rcp even to simply copy files across the network. I dont like software that doesnt talk to me! :-) I like the percentage bar that --progress gives! To my surprise, I found that, when dealing with 1GB+ files, rsync is 4-5 _times_ slower than rcp. Yes, I know that rsync is optimized for sending deltas to a file

...ions); return 0; } /************************************/ Then in R evaluate: > print.default (system.time (system(paste ("time", "bash -c './timer-test 100 > /dev/null'")))) 10.77user 0.02system 0:10.81elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+4574minor)pagefaults 0swaps user.self sys.self elapsed user.child sys.child 0.000 0.000 10.818 10.777 10.777 attr(,"class") [1] "proc_time" Expected: the sys.child time should be 0.02. > version _...

Well, maybe this is sort of related... Eric Raymond has written an article for the Linux Journal on how to build an Ultimate Linux Box. You can find the whole thing at http://www2.linuxjournal.com/cgi-bin/frames.pl/articles/style/0014.html The machine is said to compile the Linux 2.4.9 kernel in 1 min. 50 sec. I wonder how long it might take to build R on this beast... Cheers, Andy >

Hi, I don''t know if this has been discussed before, but have you thought about adding LZO compression to ZFS? One zfs-fuse user has provided a patch which implements LZO compression, and he claims better compression ratios *and* better speed than lzjb. The miniLZO library is licensed under the GPL, but the author specifically says that other licenses are available by request. Has this

...nough RAM, or with other programs competing for RAM, you are likely to end up fighting with your OS/hardware's virtual memory system. When I try to run it on a 16Gb system it churns for an hour or so before getting killed, and /usr/bin/time reports a huge number of page faults: 312523816inputs+0outputs (24761285major+25762068minor)pagefaults 0swaps You are probably experiencing something similar. There may be opportunities for more tuning of the GC to better handle running this close to memory limits, but I doubt the payoff would be worth the effort. Best, luke > It would help if gcinfo()...

On 11/24/20 11:27 AM, Jan Gorecki wrote: > Thanks Bill for checking that. > It was my impression that warnings are raised from some internal > system calls made when quitting R. At that point I don't have much > control over checking the return status of those. > Your suggestion looks good to me. > > Tomas, do you think this could help? could this be implemented? I think