On Wed, Jun 11, 2014 at 1:26 PM, Ian Daniher explodingm...@gmail.com
wrote:
Output of make check for those of you who are interested.
failures:
[run-pass] run-pass/intrinsic-alignment.rs
[run-pass] run-pass/rec-align-u64.rs
These are failing because it seems like we just overlooked
I have a dual core arm machine with 1GB of RAM keeping up with rust master
- every 8hrs, it updates git, runs make install, and 8hrs later I have an
up-to-date rustc w/ libs.
No swap, no compression kmods, just a build of rustc libs that passes
(almost) all tests.
Output of make check for those of you who are interested.
failures:
[run-pass] run-pass/intrinsic-alignment.rs
[run-pass] run-pass/rec-align-u64.rs
[run-pass] run-pass/stat.rs
test result: FAILED. 1469 passed; 3 failed; 32 ignored; 0 measured
On Wed, Jun 11, 2014 at 12:15 PM, Ian
I tried building rust in a VM with 1GB of memory and it seems only
zswap works. With zram-only solution without any real swap I was not
able to compile rust at all. The compiler generated out-of-memory
exception with zram configured to take 30-70% of memory. With zswap
enabled,
1GB is close-ish to the 1.4GB last reported (over a month ago!) by
http://huonw.github.io/isrustfastyet/mem/.
Are there any workarounds to push the compilation memory down? I'm also
exploring distcc, but IRFY has a bit of semantic ambiguity as to whether or
not it's 1.4GB simultaneous or net
1.4GB peak, consumed by rustc and every child process. The bencher is
currently running after being down for a while, so it will fill in
today. There are no real workarounds.
On Thu, Jun 5, 2014 at 11:13 AM, Ian Daniher explodingm...@gmail.com wrote:
1GB is close-ish to the 1.4GB last reported
Have you considered to use zram? Typically the compression for
compiler memory is over a factor of 3 so that can be an option as the
performance degradation under swapping could be tolerable. A similar
option is to enable zswap, but as the max compression with it is
effectively limited by factor