X-Spam-Check-By: sourceware.org To: cygwin AT cygwin DOT com From: Hans Horn Subject: Re: howto use ramdrive to speed-up cygwin Date: Tue, 29 May 2007 18:19:57 -0700 Lines: 73 Message-ID: References: <465CC4A2 DOT FA6D563A AT dessent DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) In-Reply-To: <465CC4A2.FA6D563A@dessent.net> X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Brian Dessent wrote: > Hans Horn wrote: > >> Could somebody give me a few pointers as to how to use/configure a >> ramdrive to speed-up cygwin. >> >> There was a posting a few weeks ago >> (http://sourceware.org/ml/cygwin/2007-05/msg00121.html) in which Brian >> Dessent mentions that he is using a ramdrive for building gcc. >> >> Brian, would you mind disclosing a few more details about this? > > There's nothing really that exciting about what I did, it was mainly for > running the gcc testsuite that I was experimenting with ways to make the > time pass faster. I noticed from both the HD light and from > sysinternals' FileMon that there was constant reading/seeking of the > xgcc under test, so I put the whole build directory on a ramdisk. > > Obviously, you want to compress the ramdisk and you also have to either > have a lot of RAM or not build all languages. Ada and Java in > particular will kill you, as they generate a ton of temporary binaries > when running the testsuite, and these all have full debug info by > default. A full three stage bootstrap of all languages plus running the > testsuite currently occupies 7.45 GB in my build dir, so obviously you > have to do some paring down if you want to fit that all. I can't > remember if I also moved /usr/bin onto the ramdrive or not. I think I > did with a stripped down /usr/bin from a minimal install. The mount > command makes it easy to relocate dirs physically but leave them in the > same location in the posix filespace. > > You can also play around with removing -g from TARGET_CFLAGS and > "bootstrap-lean" to save space, but I don't remember if those helped or > not. I remember getting a little frustrated that there were so many > different CFLAGS to specify and I was never able to get them all so as > to have the result be no bloating debug info. Off the top of my head > there's something like: > > BOOT_*FLAGS - for the stage 1 bootstrap > STAGE_*FLAGS - for stage 2, 3 > TARGET_*FLAGS - for the target libraries > > ...And then I think there's a few more nonstandard ones for the Ada > runtime and perhaps a couple more that I missed. Alternatively there's > always LDFLAGS="-s" which might have been easier. Anyway, getting back > on topic. > > This is not a general purpose solution to speeding Cygwin up, it was > just for the particular purpose of running the testsuite, which current > takes for-frickin-ever because of whatever it is that dejagnu does that > causes every single spawn of a test to hit the disk. You would think > the Windows system disk cache would kick in and prevent having to do > this sillyness, but it never did; the HD light never went out despite > spawning the same binaries over and over again time after time. > > Brian > Hi Brian, thx for responding! I wasn't aiming for building gcc ! Instead I was rather interested in the ramdisk aspect of that particular posting, and how I may be able to use the idea to perhaps speedup cygwin in general (speedier compilations are of course welcome!). What ramdisk software did you use? Do you have some sort of automated setup that places /bin onto the ramdisk at boot time, and takes care of the appropriate mount? In case my questions sound naiive - well, that's just what they are. I'm simply trying to find ways to make things go faster. thx again, H. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/