Re: [ALACPP] GCC and friends

[Christopher Smith <x@xxxxxxxx>]

On Wed, 2004-08-11 at 15:38, Jon Stewart wrote:
> > Ugh... nothing will kill your compile times more than encrypted RAID. :-(
> 
> If I find that I'm getting disk-bound, I might throw in a fat wad of RAM. 
> Right now I'm at 256MB on a 900MHz Duron. I'm running reiser 3.6 as my 
> filesystem and a 2.6.7 kernel. The software raid and disk encryption is 
> via the new device mapper way of doing things; cryptoloop seemed pretty 
> scary. I've yet to do any serious profiling as I'm still working on 
> low-hanging fruit (e.g. ccache). Running X is the single biggest thing I 
> can do to kill performance (my graphics hardware sucks).

So, the big penalty with the crypto stuff is that you don't get much
benefit from DMA transfers, and your paging gets kind of funny. Still,
whatever works for you.

> I want something that's pretty transparent so I can understand it, and
> I want something that's secure. Slackware has been a good distro for me
> in those regards. I have a pretty good handle on what my machine is
> doing. When I feel more comfortable with the build tools, I may move
> on to Gentoo.

Believe me, if you think you know what's going on with your system
when you install Slackware, you'll learn sooo much more when you install
Gentoo. ;-) From a security standpoint, I think you'll find Gentoo's
kernel includes a lot more patches for doing security stuff than
Slackware.

> > 3.4.1 has anumber of other nice features, including a much better parser 
> > and an actually usable iostreams library (large file support *finally*).
> 
> Heh. You search engine folks with your large files.

I dunno. These days >4GB hardly seems like a large file. :-(

> > > I'm using subversion for source control (SO much better than CVS).
> > 
> > I'm partial to arch, but hey, anything is better than CVS.
> 
> I use SourceSafe at work, and I find that it is no worse than CVS on a 
> day-to-day basis. Which is pretty sad commentary. :-)

Yeah, and suggests SourceSafe has improved dramatically since I last
used it. ;-)

> Subversion seems to have the big 'Mo in the community. When I get to the 
> point where I need better branch development support, then I'll reconsider 
> my options (or if Subversion gets too slow, I'll switch to Perforce). I 
> don't know why, but I always feel reassured when a piece of open source 
> software has good, working Windows support, with a double-clickable 
> installer, and quite a bit of documentation. It was pretty easy to get up 
> and running; so far, so good.

Yeah, see I see lack of Windows support as a feature. ;-)

> > Setting up a cross compiler can be a pain, although Dan Kegel as a nice 
> > how-to. That said, depending on the relative power of the other box, 
> > distcc can be a huge win.
> 
> 
> Yes, I stumbled upon Dan's page. I might have to try his tool out. I just 
> had the native build of 3.4.1 fail on my Mac, so now I am feeling more 
> determined to do this and solve it. If I could get my Mac to help out with 
> linux-x86 builds, that would be a huge educational windfall, whatever the 
> performance benefit. My iMac is roughly the same speed as my linux box. I 
> have a relatively fast Dell laptop wending its way through our IT 
> department.

I find distcc is awesome for laptop compiles. Typical laptop hard drives
are so slow that it really hurts build times. Much better to fire a job
off over to a machine with a real hard disk.

> I've used ant before, and it's cool. But, yeah, not so much with the C++ 
> support.

I've heard that the cpptask is much better than it used to be, so if
you're curious you might want to check it out.

> I'm subscribed to boost-users, and their build environment seems 
> to be a frequent source of errors for people. Part of this is a lack of 
> organization, but I can't help but feel that part of it is a reliance on a 
> non-standard build tool.

Heck, their version of bjam is different from the regular one. I think
that's a pretty bad sign. :-(

--Chris
_______________________________________________
alacpp mailing list
alacpp@xxxxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/alacpp