Manual vanilla build also working [documentation update]

[MagaTailor]

Hi,

I've just successfully built a nightly version of rustc (using local llvm 3.6 and no jemalloc) using the provided stage0 snapshot on my Odroid C1.

I think the readme could be improved by including this option as well. (speeds up the build and the produced rustc uses less memory also enabling dynamic linking of rust libs by not mixing different allocators)

The command line used:

./configure --disable-jemalloc --disable-valgrind-rpass --disable-valgrind --disable-docs --llvm-root=/usr --enable-local-rust --local-rust-root=/home/odroid/stage0

Needless to say it's working equally well :)

To try out the proposed changes, use the scripts from my fork.

[warricksothr]

I'll admit, that sounds good. But not using jemalloc should result in worse memory consumption.

http://smallcultfollowing.com/babysteps/blog/2014/11/14/allocators-in-rust/

I'll have to do some reading. I'm on business and don't have a lot of project time, but I'll see what I can find related to this.

Thanks!

[MagaTailor]

Just a test case for the readme (using local llvm is the main thing) - I'm not advocating anything here as it's still possible to switch to the system allocator in rust programs with extern crate alloc_system. (besides, as long as the std library has not been stabilised, dynamic linking doesn't make much sense either)

[MagaTailor]

Anyway, it might be a useful idea (and somewhat original) to provide the stable releases in both flavours. On memory constrained arm systems the default jemalloc settings seem to use more memory which can hurt real world performance due to swapping.

At least this was my experience with the binary-trees benchmark.

[warricksothr]

So here's an interesting question. Was it just memory savings while compiling the benchmark, or did you see memory savings while running it as well? Also what platform were you running it on?

I'll need to redesign the project to support multiple types of builds from the same container, but I'm not opposed to building stable and beta builds with unique tuning (as a container for each is going to become a prohibitively large repository).

[MagaTailor]

I'm talking about the benchmark proper on a 1GB linux platform (Odroid C1). Benchmarking the compilers themselves is also interesting but decidedly of secondary importance (unless all you do is compile & recompile all day long :))

I'm beginning to think that all arm processors with puny amounts of cache are going to be handicapped by the default allocator (meaning two allocators really) unless memory fragmentation is a big issue.

Part of this runtime effect could be achieved even with a jemalloc rustc after putting extern crate alloc_system in the compiled source code so it's not necessary to use a pure system alloc compiler. The only time it becomes necessary is when dynamic linking of rust libs is needed.

https://www.reddit.com/r/rust/comments/3p0ljg/forcing_rustc_to_use_the_system_allocator