Skip to Content.
Sympa Menu

sm-discuss - RE: [SM-Discuss] License Choices

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Aaron Brice <abrice2 AT cox.net>
  • To: Aaron Brice <abrice2 AT cox.net>
  • Cc: Phil/CERisE/KG6MBQ <cerise AT littlegreenmen.armory.com>, sm-discuss AT lists.ibiblio.org
  • Subject: RE: [SM-Discuss] License Choices
  • Date: 22 Jul 2002 21:54:40 -0700

Test Results:
cast -c -r mozilla: 47m 2.173s
make (nice +10) in an ext3 filesystem: 42m 6.5s

Both run with the same configure options and compiler optimizations.

If you add the time it takes to download the source file and run
configure to the ext3 time, it ends up being about the same amount of
time.

Interesting, I had always assumed that tmpfs was there for speed
reasons. But I still like the compiling in tmpfs system, and don't
really see a benefit of getting rid of it..

Aaron


On Sun, 2002-07-21 at 18:24, Aaron Brice wrote:
> Would be easy and interesting to compare. I have a 1.2 GHz Athlon with
> 384M of memory. I'll do a "time cast -c -r mozilla" and compare it to a
> "time make" of the mozilla source in my home directory. People with
> lower and higher performance computers could maybe do the same..
>
> On Sun, 2002-07-21 at 15:54, Phil/CERisE/KG6MBQ wrote:
> > Glenn Shannon insolently stated:
> >
> > > I believe the choice to use tmpfs was because compiling in memory is
> > > faster.
> >
> > Ahh yes, I've heard this myth. It sounds nice, doesn't it? Almost
> > believable. I think there's good reason to doubt it though.
> > In theory, compiling memory is faster because memory access is
> > faster than disk access.
> > In practice, where you've just unloaded a rather large tarball on
> > memory, it seems destined to end up in swap which will incur disk
> > access. Two of them at minimum in fact. One to write to virtual
> > memory, the other to read it back out.
> > I'm ignoring lots of other factors considering that disk access is
> > an order of magnitude slower than CPU time. It seems like disk access
> > is the thing to measure here. With that in mind, it seems like using
> > tempfs (which isn't exactly the most sophisticated fs in the world...)
> > over your native filesystem (which will almost certainly be more
> > sophisticated than tempfs and should have faster algorithmic run times)
> > is going to hopelessly slow things down.
> >
> > -Phil/CERisE
> >
> > _______________________________________________
> > SM-Discuss mailing list
> > SM-Discuss AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/sm-discuss
>
>
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss






Archive powered by MHonArc 2.6.24.

Top of Page