search for: 41mb

...result I got is as follows: >Error: Cannot allocate vector of size 41148 Kb >In addition: Warning Message: >Reached total allocation of 255 Mb. See help(memory) >memory.size(max=TRUE) 250,834,944 >memory.size() 95,052,192 In other words. R should be able to allocate the vector of 41Mb!!!! What is the problem? I read the documentation concerning memory, the CHANGES file and the R-mailing list. In addition to the problem mentioned above, I'm not able to apply the function: > --min-vsize=vl --max-vsize=vu --min-nsize=nl --max-nsize=nu Can anybody explain what is happening...

Hi All, I''m very happy to announce the release of Locomotive 1.0.0. Locomotive is a one-click development solution for Rails on Mac OS X. See more details at http://locomotive.sourceforge.net Get it at: http://prdownloads.sourceforge.net/locomotive/Locomotive_1.0.0.dmg?download What''s New? =========== * Server bundle updated to lighttpd 1.4.8 * Server bundle updated to

...ollecting might help, so I added a Kernel.sleep 1 every 100 or so queries. This made it seem like it worked better, but I could still get it to fail, so I might be imagining any improvement. I have plenty of free RAM in my machine, and when the Mongrel process hangs, it uses anywhere from 35-41MB. The amount of CPU usage while hung is very small. I am not opening any files on the filesystem. I am not rotating my log files. I''m using Rails 1.2.3, os Mac OS X 10.4.9, in development mode, Mongrel 1.0.1 and Oracle 10.2. I''m using oracle instant client 10.1 and ruby-oc...

https://bugzilla.netfilter.org/show_bug.cgi?id=1469 Bug ID: 1469 Summary: Bison reported unused tokens in `nft` Product: nftables Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 Component: nft Assignee: pablo at netfilter.org

...sks. Even though DAGCombine has the same transforms, it causes some pretty bad regressions: External/SPEC/CINT95/147_vortex/147_vortex 0.294 0.322 +9.6% +40mB MultiSource/Benchmarks/Olden/tsp/tsp 0.680 0.748 +9.9% +41mB SingleSource/Benchmarks/Shootout-C++/except 0.116 0.128 +10.8% +45mB SingleSource/Benchmarks/Shootout/strcat 0.102 0.113 +11.1% +46mB SingleSource/Benchmarks/Shootout-C++/hash 0.455 0....

On Tue, Apr 17, 2012 at 12:23 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > I am not sure how best to fix this. If possible, InstCombine's > canonicalization shouldn't hide arithmetic progressions behind bit masks. The entire concept of cleverly converting arithmetic to bit masks seems like the perfect domain for DAGCombine instead of InstCombine: 1) We know the

Hello, I am a newbie to wx and wxruby, I just built wxruby2 on my gentoo box. At first it did not work. So I post a little message,it might help others. At first a cryptic message was shown SWIG Version 1.3.21 Copyright (c) 1995-1998 University of Utah and the Regents of the University of California Copyright (c) 1998-2003 University of Chicago Compiled with i686-pc-linux-gnu-g++

Hi! i just downloaded 20010510 sources, compiled and installed it on my RedHat 7.1 linux box. I have several vfat (fat32) and linux (ext2) partitions on my pc ( i also have a windows98 installation). I have configured the fat32 parrtition like: [Drive E] "Path" = "/deposito" "Type" = "hd" "Filesystem" = "vfat" and the ext2 like:

Look at this silly function: $ cat small.c unsigned f(unsigned a, unsigned *p) { unsigned x = a/4; p[0] = x; p[1] = x+x; return p[1] - 2*p[0]; } GCC turns this into straightforward code and figures out the 0 return value: shrl $2, %edi movl %edi, (%rsi) addl %edi, %edi movl %edi, 4(%rsi) movl $0, %eax ret LLVM optimizes the code: $ clang -O -S -o- small.c -emit-llvm define i32

...2 15.9 134.1 0.9 I''m getting distinctly non-linear scaling here. Writes: 4 disks gives me 123MB/sec. Raid0 was giving me 270/8 =33Mb/sec with cpu to spare (roughly half on what each individual disk should be capable of). Here I''m getting 123/4= 30Mb/sec, or should that be 123/3= 41Mb/sec? Using 30 as a basline, I''d be expecting to see twice that with 8 disks (240ish?). What I end up with is ~135, Clearly not good scaling at all. The really interesting numbers happen at 7 disks - it''s slower then with 4, in all tests. I ran it 3x to be sure. Note this was a nat...

...e replica 2 transport tcp $(for i in b c d e f g h i j k l m ; do for n in 1 2; do echo -n "gluster0$n:/data-$i "; done; done) As expected, the overhead here is larger. initial file creation started slowly at 45MB/s and peaked around 105MB/s, 50 clients saw a total bandwidth of about 41MB/s (3) I ran other tests across all 10 backend bricks, but never went beyond ~ 80MB/s when using 4 disk raid0 over 10 servers. All tests were run with glusterfs 3.2.5 on Debian Squeeze, md-software raid, xfs file system, "default" settings for all of these, except using the deadline I...