similar to: Ultimate Linux Box (was RE: optimal windows R machine)

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

Hi! Anyone else experiencing performance problems when using the new monorepo? My experience is that performance of gitk (and git log) sometimes is really bad when working in the monorepo. I've mainly seen it when using gitk on specific files/directories, but since gitk seems to be using "git log --no-color -z --pretty=raw --show-notes --parents --boundary HEAD -- <file>" it

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

Óscar Fuentes <ofv at wanadoo.es> writes: > 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

Full_Name: Manuel L?pez-Ib??ez Version: R version 2.6.2 (2008-02-08) OS: linux-gnu Submission from: (NULL) (164.15.10.156) This is only relevant for CPU intensive child processes. Otherwise, the problem is not obvious. Therefore, we need a CPU intensive program like this one: /************************************/ /*** Compile with: gcc -o timer-test -O0 timer-test.c -lm */ #include

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

Hi there. First of all, I'd like to congratulate to developers for making a free specification and LGPLed decoder/encoder. :-). I did some test, ripping 17 tracks of my CD and converting them to both MP3 and OGG format. MP3 encoder/player was Lame 3.70 OGG encoder/player was from a Saturday nightly tgz package. ------------------------------------ MP3: LAME-3.70 mpg123-0.59r-4 MP3: lame -S

Hi there. First of all, I'd like to congratulate to developers for making a free specification and LGPLed decoder/encoder. :-). I did some test, ripping 17 tracks of my CD and converting them to both MP3 and OGG format. MP3 encoder/player was Lame 3.70 OGG encoder/player was from a Saturday nightly tgz package. ------------------------------------ MP3: LAME-3.70 mpg123-0.59r-4 MP3: lame -S

Olly Betts writes: > On Sun, Apr 10, 2016 at 04:47:01PM +0200, Jean-Francois Dockes wrote: > > Some might notice the 50% index size increase. Excessive index size is > > already one relatively rare, but recurring complaint. Except if I did > > something wrong: I'm actually quite surprised by it. > > Did you try compacting the resulting databases? > >

Hi, I'm running centos-4.4 on an SMP system with 4 dual core opterons (2.4 GHz), and 16 GB memory. The disk drives are 500 GB SATA-Drives. Wondering about times for dd command performance and rm command performance in an empty machine (the filesystem has been made with "mkfs.ext3 /dev/sd...", nothing more) 1. Making a new 3 GB (1024 x 3megabytes blocks) file with dd needs 10.18

...but 2.4.3 worked fine. this is linux 2.4.18 with glibc 2.2.5 and libz 1.1.4, if it matters, on both source and dest. apparently something about trying to send a file ending with .iso gives rsync a fit if the -z [compress] option is used. $ time rsync -Pzv --stats cd1_en_binary.iso mail.cheek.com::root/home/ericom Password: cd1_en_binary.iso rsync: error writing 16385 unbuffered bytes -

On Tue, 24 Nov 2020, Jan Gorecki wrote: > As for other calls to system. I avoid calling system. In the past I > had some (to get memory stats from OS), but they were failing with > exactly the same issue. So yes, if I would add call to system before > calling quit, I believe it would fail with the same error. > At the same time I think (although I am not sure) that new allocations

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.

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

I used "/usr/bin/time" to time how long it took to join a DC to our domain. It took 9 hours, 54 minutes and 16 seconds. The logs follow: Committing SAM database Sending DsReplicateUpdateRefs for all the replicated partitions Setting isSynchronized and dsServiceName Setting up secrets database Joined domain DIGIPEN.EDU (SID S-1-5-21-REDACTED) as a DC 35461.84user 26.13system

On Mon, Sep 26, 2016 at 8:08 AM, Carsten Mattner <carstenmattner at gmail.com> wrote: > On Mon, Sep 26, 2016 at 4:25 PM, Teresa Johnson <tejohnson at google.com> > wrote: > > No worries, thanks for the update. Teresa > > 2048 wasn't enough. Bumped to 4096. Only 1300 ninja targets left. > > Once I've been successful with this, I might try building a

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

When I copy a file(13Megs) from /home/ to /tmp/, sync takes almost 2 minutes. When I copy the same file to /usr/local/, sync returns almost right away. Both filesystems are ext3 and are on the same harddrive. When sync is running, the harddrive light stays on but I don't hear it doing anything. dmesg doesn't show any errors either. Below is the `time` output for each command. If you

Olly Betts writes: > On Mon, Apr 11, 2016 at 09:54:36AM +0200, Jean-Francois Dockes wrote: > > The question which remains for me is if I should run xapian-compact > > after an initial indexing operation. I guess that this depends on the > > amount of expected updates and that there is no easy answer ? > > I think it's not obvious whether it's a good plan

PureComponents Ultimate Suite V2008.1 - The cheapest component suite there is! PureComponents offer you component suite for excellent price of 1 USD per component. Purchase the set of 79 components for 79 USD. Purchase 1 year subscription by June 30, and save 30%! http://www.purecomponents.com/