Closed indiv0 closed 10 years ago
It's hard to tell without a backtrace (could you run the rustc build in gdb?) but I'd imagine the illegal instruction is coming from a call to abort. Since memory use seems to be high, a good guess would be a malloc failure.
Alright I'll give it a shot tomorrow. On Jul 2, 2014 10:13 PM, "Steven Fackler" notifications@github.com wrote:
It's hard to tell without a backtrace (could you run the rustc build in gdb?) but I'd imagine the illegal instruction is coming from a call to abort. Since memory use seems to be high, a good guess would be a malloc failure.
— Reply to this email directly or view it on GitHub https://github.com/rust-lang/rust/issues/15346#issuecomment-47859550.
I hope I did this right.
Here's the backtrace.
The testing environment is reproducible BTW using the Vagrant/Puppet provisioner for my project, in case you need to reproduce the issue.
How much memory do you have?
Looks like 1G from the Vagrantfile: https://github.com/Indiv0/rust-ssb/blob/master/Vagrantfile
The build is being run with 1G and peaking at 611M, as per the discussion on the piston issue tracker.
The build is running inside a VM. I can retry the build with more RAM if necessary. On Jul 3, 2014 12:52 AM, "Huon Wilson" notifications@github.com wrote:
How much memory do you have?
— Reply to this email directly or view it on GitHub https://github.com/rust-lang/rust/issues/15346#issuecomment-47866643.
Oh, yeah: can you try increasing it?
Sure thing. Running with 4 Gb now.
Build completes successfully. RAM usage peaked at 1488M
. Any idea why it's going so high? Is this expected?
Just a few days ago I was able to successfully compile Piston in the VM with only 512M of RAM.
Yes, the compiler hasn't been optimised for performance much at all (neither time nor memory), most effort has been spent implementing the language rather than tweaking the implementation details of the compiler itself. (It's definitely annoying, but hopefully we'll be able to spend more time on the compiler once most of the backwards incompatible languages changes are done.)
Closing. (Thanks for filing!)
I've isolated the performance issues to a relatively small piece of code, specifically deriving PartialOrd and Ord on a long enum. While I appreciate that rustc isn't optimized for performance, it still seems like a bug to me that compiling the code below takes almost 1.6 gb of memory, and almost 2 minutes of time:
#[deriving(PartialEq, Eq, PartialOrd, Ord)]
pub enum Key {
Unknown ,
Backspace ,
Tab ,
Return ,
Escape ,
Space ,
Exclaim ,
Quotedbl ,
Hash ,
Dollar ,
Percent ,
Ampersand ,
Quote ,
LeftParen ,
RightParen ,
Asterisk ,
Plus ,
Comma ,
Minus ,
Period ,
Slash ,
D0 ,
D1 ,
D2 ,
D3 ,
D4 ,
D5 ,
D6 ,
D7 ,
D8 ,
D9 ,
Colon ,
Semicolon ,
Less ,
Equals ,
Greater ,
Question ,
At ,
LeftBracket ,
Backslash ,
RightBracket ,
Caret ,
Underscore ,
Backquote ,
A ,
B ,
C ,
D ,
E ,
F ,
G ,
H ,
I ,
J ,
K ,
L ,
M ,
N ,
O ,
P ,
Q ,
R ,
S ,
T ,
U ,
V ,
W ,
X ,
Y ,
Z ,
Delete ,
CapsLock ,
F1 ,
F2 ,
F3 ,
F4 ,
F5 ,
F6 ,
F7 ,
F8 ,
F9 ,
F10 ,
F11 ,
F12 ,
PrintScreen ,
ScrollLock ,
Pause ,
Insert ,
Home ,
PageUp ,
End ,
PageDown ,
Right ,
Left ,
Down ,
Up ,
NumLockClear ,
NumPadDivide ,
NumPadMultiply ,
NumPadMinus ,
NumPadPlus ,
NumPadEnter ,
NumPad1 ,
NumPad2 ,
NumPad3 ,
NumPad4 ,
NumPad5 ,
NumPad6 ,
NumPad7 ,
NumPad8 ,
NumPad9 ,
NumPad0 ,
NumPadPeriod ,
Application ,
Power ,
NumPadEquals ,
F13 ,
F14 ,
F15 ,
F16 ,
F17 ,
F18 ,
F19 ,
F20 ,
F21 ,
F22 ,
F23 ,
F24 ,
Execute ,
Help ,
Menu ,
Select ,
Stop ,
Again ,
Undo ,
Cut ,
Copy ,
Paste ,
Find ,
Mute ,
VolumeUp ,
VolumeDown ,
NumPadComma ,
NumPadEqualsAS400 ,
AltErase ,
Sysreq ,
Cancel ,
Clear ,
Prior ,
Return2 ,
Separator ,
Out ,
Oper ,
ClearAgain ,
CrSel ,
ExSel ,
NumPad00 ,
NumPad000 ,
ThousandsSeparator ,
DecimalSeparator ,
CurrencyUnit ,
CurrencySubUnit ,
NumPadLeftParen ,
NumPadRightParen ,
NumPadLeftBrace ,
NumPadRightBrace ,
NumPadTab ,
NumPadBackspace ,
NumPadA ,
NumPadB ,
NumPadC ,
NumPadD ,
NumPadE ,
NumPadF ,
NumPadXor ,
NumPadPower ,
NumPadPercent ,
NumPadLess ,
NumPadGreater ,
NumPadAmpersand ,
NumPadDblAmpersand ,
NumPadVerticalBar ,
NumPadDblVerticalBar ,
NumPadColon ,
NumPadHash ,
NumPadSpace ,
NumPadAt ,
NumPadExclam ,
NumPadMemStore ,
NumPadMemRecall ,
NumPadMemClear ,
NumPadMemAdd ,
NumPadMemSubtract ,
NumPadMemMultiply ,
NumPadMemDivide ,
NumPadPlusMinus ,
NumPadCear ,
NumPadClearEntry ,
NumPadBinary ,
NumPadOctal ,
NumPadDecimal ,
NumPadHexadecimal ,
LCtrl ,
LShift ,
LAlt ,
LGui ,
RCtrl ,
RShift ,
RAlt ,
RGui ,
Mode ,
AudioNext ,
AudioPrev ,
AudioStop ,
AudioPlay ,
AudioMute ,
MediaSelect ,
Www ,
Mail ,
Calculator ,
Computer ,
AcSearch ,
AcHome ,
AcBack ,
AcForward ,
AcStop ,
AcRefresh ,
AcBookmarks ,
BrightnessDown ,
BrightnessUp ,
DisplaySwitch ,
KbdIllumToggle ,
KbdIllumDown ,
KbdIllumUp ,
Eject ,
Sleep ,
}
(Output from terminal when compiling using time
to monitor resource usage)
$ /usr/bin/time -v rustc src/keyboard.rs --crate-type lib
Command being timed: "rustc src/keyboard.rs --crate-type lib"
User time (seconds): 106.55
System time (seconds): 3.61
Percent of CPU this job got: 94%
Elapsed (wall clock) time (h:mm:ss or m:ss): 1:56.44
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): 1597512
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 443437
Voluntary context switches: 1088
Involuntary context switches: 11284
Swaps: 0
File system inputs: 16
File system outputs: 1688128
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
Oh dear, that is absurd!
I'm going to open a separate issue about that program.
Opened as #15375
Attempting to compile the piston project results in the following error:
Compiling a simple "Hello world!" function works fine, so the rust compiler is working.
Attempting to go through the piston issue tracker resulted in a dead end, as this appears to be an issue with rust. Full discussion can be viewed here.
Sidenote: as discussed on the piston issue tracker, is the high RAM use while compiling expected (
>1G
)?