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):
