[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: MLton on PowerPC: voltaire's Christmas wish?



On Wed, Dec 22, 2004 at 09:42:01AM +0100, Ingo Juergensmann wrote:
> Well, having more RAM is always nice, but IMHO there's something wrong with
> MLton when it needs that much RAM for building. 

It's a whole-program optimizing compiler...
That means it analyzes all of the source code at once.
When compiling a large project (MLton is ~145k lines) it needs memory.

I agree that this is unfortunate; however, if you check out the runtime
performance of MLton compiled applications, you'll see the advantages. =)

> buildd=> select distinct ram, count(*) from status group by ram;
>  ram  | count |  arch
> ------+-------+---------
>    48 |     1 | m68k
>    64 |     6 | arm mipsel m68k mips
>    80 |     1 | m68k
>    90 |     1 | mips
>    96 |     3 | mips m68k
>   128 |    11 | arm mips m68k
>   132 |     1 | m68k
>   136 |     1 | m68k
>   144 |     2 | m68k
>   256 |     4 | m68k mips s390
>   320 |     1 | powerpc
>   512 |     6 | amd64 sparc alpha
>   768 |     1 | hppa
>  1024 |     2 | alpha hppa
>  1536 |     1 | amd64
>  2048 |     1 | sparc
>  4096 |     2 | alpha ia64

Thanks a lot for this list! I've been trying to find it for a month.
Where did you get this?

> As you can see, many buildds are low on RAM. How do you want to solve that?

I am not planning on porting MLton to any platform with less memory.
PowerPC is the exception; lots of people use it and it can handle the RAM.
I've already done hppa and sparc. amd64, ia64, and alpha need some 64bit
cleanups, so I was planning on doing that after the easier 32bit ports.

> but maybe it's possible for MLton as well to lower the RAM requirements?
> Of course you would need to know where and why the RAM is needed... 

Well, I'm in contact with the developers of MLton, and they seem to think
this is an inherent disadvantage of whole-program optimization. Their (valid
imo) argument is that requiring a powerful build machine is better than
requiring a powerful machine to run the resulting binary.

-- 
Wesley W. Terpstra



Reply to: