BLU Discuss list archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss] smallest board that can handle 32 GB RAM
- Subject: [Discuss] smallest board that can handle 32 GB RAM
- From: smallm at panix.com (Mike Small)
- Date: Fri, 09 May 2014 17:55:55 -0400
- In-reply-to: <536B80EC.2080005@borg.org> (Kent Borg's message of "Thu, 08 May 2014 09:04:44 -0400")
- References: <536AF0F7.80707@gmail.com> <536B80EC.2080005@borg.org>
Kent Borg <kentborg at borg.org> writes: > Here is why I ask: I am just shifting things over to a new 16GB > machine. I got that much because I could and it was pretty cheap. But > I don't know what I am going to do with all that. That is a *bleep* of > a lot of RAM. I was just reading the release notes for gcc 4.9. When I read this part, I thought of this thread, your post in particular: Memory usage building Firefox with debug enabled was reduced from 15GB to 3.5GB; link time from 1700 seconds to 350 seconds. -- http://gcc.gnu.org/gcc-4.9/changes.html And just the other day I thought I'd like to build firefox with debugging info since I see crashes running with the X security extension (or is it XACE I'm actually using, I don't even know... never mind). Given that my laptop has 1.5 GB and my desktop 384 MB that seems right out. But if you have 16 GB (or 32 GB!?!) you should definitely recompile all your programs with debugging symbols in case one crashes. It's very annoying when programs crash and you don't have symbols. Or heck, with that much memory isn't it about time our programs failed more like this... EVAL: undefined function MEMCPY [Condition of type SYSTEM::SIMPLE-UNDEFINED-FUNCTION] Restarts: 0: [USE-VALUE] Input a value to be used instead of (FDEFINITION 'MEMCPY). 1: [RETRY] Retry 2: [STORE-VALUE] Input a new value for (FDEFINITION 'MEMCPY). 3: [RETRY] Retry SLIME REPL evaluation request. 4: [*PROCESS-INPUT] Continue reading input. 5: [ABORT] Return to SLIME's top level. --more-- Backtrace: 0: [460] frame binding variables (~ = dynamically): | ~ SWANK::*SLDB-STEPPING-P* <--> NIL 1: [457] frame binding variables (~ = dynamically): | ~ SWANK::*SLDB-LEVEL* <--> 0 2: [454] frame binding variables (~ = dynamically): | ~ *PACKAGE* <--> #<PACKAGE COMMON-LISP-USER> ...
- Follow-Ups:
- [Discuss] smallest board that can handle 32 GB RAM
- From: me at mattgillen.net (Matthew Gillen)
- [Discuss] OT: Cambridge seeks applicants for broadband task force
- From: sronan at panix.com (Stephen Ronan)
- [Discuss] smallest board that can handle 32 GB RAM
- References:
- [Discuss] smallest board that can handle 32 GB RAM
- From: tmetro+blu at gmail.com (Tom Metro)
- [Discuss] smallest board that can handle 32 GB RAM
- From: kentborg at borg.org (Kent Borg)
- [Discuss] smallest board that can handle 32 GB RAM
- Prev by Date: [Discuss] Online vs. offline user ids
- Next by Date: [Discuss] OT: Cambridge seeks applicants for broadband task force
- Previous by thread: [Discuss] smallest board that can handle 32 GB RAM
- Next by thread: [Discuss] OT: Cambridge seeks applicants for broadband task force
- Index(es):