compiling hangs at core_ops_cg.c

[K Stol]

hi,

I have trouble compiling the current distribution of parrot.
I checked it out from cvs, that didn't work, so I decided to download a
snapshot (latest, 31/3).

Compiling on my winXP computer is going ok (P3/450mhz), but while
compiling on my linux
server (amd k6-2/233 mhz), it hangs on core_ops_cg.c
I tried several times, but it doesn't continue after that. When I
execute "top" I can see the memory the program
takes (ccl or something?) LOTS of memory, about 200. It has about 128MB,
+ 128 MB Swap.

Does anybody have a clue?

Kind regards,

Klaas-Jan

[Dan Sugalski]

Oh, it'll finish, but it may take a while.

The computed goto core (which is what core_ops_cg.c has in it) is one
*huge* function. It takes a pretty massive amount of memory to
compile--gcc topped out at 190M the last time I checked, but it might
be a bit worse now. Even without swapping it takes my 600MHz G3
laptop nearly a minute to compile it under normal circumstances.
That'd be about three to four for the CPU you've got, and when you
throw in swapping I can see the compile time for that module hitting
15-20 minutes.

If you give the --cgoto=0 flag to Configure.pl it'll skip that core
in the build.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

[Jerome Quelin]

Dan Sugalski wrote:
> That'd be about three to four for the CPU you've got, and when you
> throw in swapping I can see the compile time for that module hitting
> 15-20 minutes.

At least. FYI, I ran into the same problem some months ago. I had 128 Mb
on my P4 1.3GHz Linux box. The total compile time was about 40 minutes
because of swapping.

I added 256 Mb RAM and I now compile parrot in less than 5 minutes.

Jerome
--
jqu...@mongueurs.net

[Stefan Lidman]

I am on linux and it worked for me with a new cvs copy. I had to do a
"make realclean" first though. Usually that is not neccesary.

/Stefan

[Art Haas]

Jerome Quelin wrote:

Hi.

Newer GCC releases are _much_ better at compiling this file than older
releases. GCC-3.3 is better than GCC-3.2, GCC-3.4 is better than GCC-3.3,
but best of all is GCC-3.5, as it compiles this file in usually less than
5 minutes and requires the least memory of all. I'm building on a 200 MHz
Pentium - no joke - so the latest GCC has been a trememdous improvement.

Even though GCC has been getting slower for compiling other code, when
building Parrot, and in particular the core_ops_cg.c file, GCC has been
getting much, much better.

Art Haas

[K Stol]

Art Haas wrote:

Thanks for your tips, all!
I just had to be patient with the old computer. It compiles now (eventually)

Klaas-Jan

[Larry Wall]

On Fri, Apr 02, 2004 at 07:02:52AM -0600, Art Haas wrote:
: Newer GCC releases are _much_ better at compiling this file than older

: releases. GCC-3.3 is better than GCC-3.2, GCC-3.4 is better than GCC-3.3,
: but best of all is GCC-3.5, as it compiles this file in usually less than
: 5 minutes and requires the least memory of all. I'm building on a 200 MHz
: Pentium - no joke - so the latest GCC has been a trememdous improvement.
:
: Even though GCC has been getting slower for compiling other code, when
: building Parrot, and in particular the core_ops_cg.c file, GCC has been
: getting much, much better.

Hmm, if it's getting better for you and worse for others, that might
well mean that GCC is just getting better at figuring out when to do
a worse job of compiling. "Gee, they just handed me a 200k function.
Maybe I'll just skip the basic-block analysis today..."

So you really need to compare the outputs of the two compilers before
you can call it "better" in an unqualified sort of way. I'm not saying
it isn't better--it might well be that they've performed a miracle.
Or maybe they're using Parrot code as the stress test for GCC,
and optimizing on the basis of that. That'd be cool...sort of like
optimizing for a particular set of benchmarks.

Larry

[Leopold Toetsch]

K Stol <new...@home.nl> wrote:
>>
> Thanks for your tips, all!
> I just had to be patient with the old computer. It compiles now (eventually)

And if you want fast recompiles (w/o code changes) then install ccache.

,--[ man ccache ]--------------------------------------------------
| DESCRIPTION
| ccache is a compiler cache. It speeds up re-compilation of
| C/C++ code by caching previous compiles and detecting when
| the same compile is being done again.
`------------------------------------------------------------------

> Klaas-Jan

leo

[Aaron Sherman]

On Fri, 2004-04-02 at 12:26, Larry Wall wrote:

> Hmm, if it's getting better for you and worse for others [...] it

> might well be that they've performed a miracle.

Actually, they may well just be optimizing that work for memory, rather
than CPU, and could be making some tragic choices with respect to
blowing the cache which (on modern machines that lean on L1 and L2 cache
a great deal) could lead to worse performance than on a machine that
didn't have the large cache in the first place....

I have come to hate L2 cache for so many reasons. It's the primary
reason, for example, that hyper-threading hoses our application at work.
HT would be a very nice tool, but if you blow the cache you get worse
performance than without :-(

--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback