Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce stage1 peak memory usage to within 3.5 GiB #471

Closed
ghost opened this issue Sep 13, 2017 · 4 comments
Closed

Reduce stage1 peak memory usage to within 3.5 GiB #471

ghost opened this issue Sep 13, 2017 · 4 comments
Labels
enhancement Solving this issue will likely involve adding new logic or components to the codebase. stage1 The process of building from source via WebAssembly and the C backend.
Milestone

Comments

@ghost
Copy link

ghost commented Sep 13, 2017

No description provided.

@andrewrk andrewrk added enhancement Solving this issue will likely involve adding new logic or components to the codebase. optimization labels Sep 13, 2017
@andrewrk andrewrk added this to the 0.2.0 milestone Sep 13, 2017
@andrewrk andrewrk modified the milestones: 0.2.0, 0.3.0 Nov 14, 2017
@andrewrk andrewrk modified the milestones: 0.3.0, 0.4.0 Feb 28, 2018
@tiehuis
Copy link
Member

tiehuis commented Mar 30, 2018

I've just checked this on the current latest master to get some more actionable results:

In summary the following tests were the most memory intensive. I did not hit anywhere near 4Gb, but with other things running on the system at the same time it isn't unlikely to hit that.

  • test-std 880Mb peak
  • test-compiler-rt 1.76Gb peak

time -v

1539.64Mb

Command being timed: "zig build --build-file ../build.zig test"
	User time (seconds): 451.28
	System time (seconds): 31.24
	Percent of CPU this job got: 98%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 8:12.10
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 1576592
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 3159
	Minor (reclaiming a frame) page faults: 21121360
	Voluntary context switches: 35057
	Involuntary context switches: 132143
	Swaps: 0
	File system inputs: 507560
	File system outputs: 1051144
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 0

Massif

This seems incorrect and reporting too low.

valgrind --tool=massif --pages-as-heap=yes --massif-out-file=massif.out zig build --build-file ../build.zig test

2018-03-30-203130_1037x604_scrot

Manual \w Htop

Just to confirm I watched a run using htop.

Start: 2.66Gb
Peak: 4.36Gb

Notable peaks were 3.54Gb during test-std and 4.36Gb during test-compiler-rt so I would target those segments. The rest of the tests memory consumption were negligible in comparison.

@andrewrk
Copy link
Member

There are a lot of memory inefficiencies in the c++ compiler which I never really expect to fix. However I do want to keep the self hosted compiler memory efficient. I'm also considering having a feature where you can upper bound the memory and it would utilize disk space beyond that.

@andrewrk andrewrk modified the milestones: 0.4.0, 0.5.0 Sep 28, 2018
@andrewrk andrewrk modified the milestones: 0.5.0, 0.6.0 May 9, 2019
@andrewrk
Copy link
Member

I added -DZIG_ENABLE_MEM_PROFILE option and -fmem-report flag in #3482. @mikdusan is doing some work on this in #3502.

Here is what I observe with zig-0.5.0+e98e5d, with a fresh build (nothing cached):

  • test-std: 4.3 GiB peak
  • test-compiler-rt: 2.3 GiB peak

I'm going to clarify the requirements of stage1 here: the goal is to get stage1 memory usage down to 3.5 GiB peak for the entire test suite. The reasoning for this is straightforward: 4 GiB is how much RAM we want zig to require a CI server to have. We leave 0.5 GiB for the base system and 3.5 peak for all the tests - including building the self-hosted compiler. This number is significant because it is the memory requirement of bootstrapping.

Once this goal is accomplished we could use something like time -v -o time.txt zig build test and then look at the results, failing the build if the memory usage exceeded 3.5 GiB peak.

@andrewrk andrewrk modified the milestones: 0.7.0, 0.8.0 Oct 9, 2020
@andrewrk andrewrk modified the milestones: 0.8.0, 0.9.0 Jun 4, 2021
@andrewrk andrewrk modified the milestones: 0.9.0, 0.10.0 Nov 22, 2021
@andrewrk andrewrk modified the milestones: 0.10.0, 0.11.0 Apr 16, 2022
@andrewrk
Copy link
Member

Duplicate of #6485

@andrewrk andrewrk marked this as a duplicate of #6485 Apr 16, 2022
@andrewrk andrewrk modified the milestones: 0.11.0, 0.10.0 Apr 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Solving this issue will likely involve adding new logic or components to the codebase. stage1 The process of building from source via WebAssembly and the C backend.
Projects
None yet
Development

No branches or pull requests

2 participants