VACPP 3.08-problem with large source file? - OS2

This is a discussion on VACPP 3.08-problem with large source file? - OS2 ; All required files are in http://home.uni-one.nl/m1/BF2C.ZIP , 270 KB. A working example is already included, reproducable with: BF2C.EXE Mandelbrot.BF > Mandelbrot.C ICC Mandelbrot.C The same seems to fail with the largest known app, LostKingdom.BF. I've no idea if the LostKingdom.EXE ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: VACPP 3.08-problem with large source file?

  1. VACPP 3.08-problem with large source file?



    All required files are in http://home.uni-one.nl/m1/BF2C.ZIP, 270 KB. A
    working example is already included, reproducable with:

    BF2C.EXE Mandelbrot.BF > Mandelbrot.C
    ICC Mandelbrot.C

    The same seems to fail with the largest known app, LostKingdom.BF. I've
    no idea if the LostKingdom.EXE would work at all, but so far it seems I
    cannot compile the file LostKingdom.C produced with BF2C.EXE.

    The file LostKingdom.C is also included and should be reproducable with
    the customized BF2C.EXE:

    BF2C.EXE LostKingdom.BF > LostKingdom.C

    Is it compilable with other compilers? More important: ICC (3.08) seems
    to hang. I haven't waited hours, but the session seems dead. Rebooting
    is required to kill the CMD.EXE-sessions with eCS 1.2.

    What can I do to compile LostKingdom.C, is this reveiling an ICC-bug or
    am I just showing a problem with regads to my level of patience?

    Please note it's a kind of "stress test". I think it should work and it
    should be compilable within a reasonable period of time, without any
    ICC-switches, like the Mandelbrot-example.



  2. Re: VACPP 3.08-problem with large source file?

    A.D Fundum schrieb:
    > All required files are in http://home.uni-one.nl/m1/BF2C.ZIP, 270 KB. A
    > working example is already included, reproducable with:
    >
    > BF2C.EXE Mandelbrot.BF > Mandelbrot.C
    > ICC Mandelbrot.C
    >
    > The same seems to fail with the largest known app, LostKingdom.BF. I've
    > no idea if the LostKingdom.EXE would work at all, but so far it seems I
    > cannot compile the file LostKingdom.C produced with BF2C.EXE.
    >
    > The file LostKingdom.C is also included and should be reproducable with
    > the customized BF2C.EXE:
    >
    > BF2C.EXE LostKingdom.BF > LostKingdom.C
    >
    > Is it compilable with other compilers? More important: ICC (3.08) seems
    > to hang. I haven't waited hours, but the session seems dead. Rebooting
    > is required to kill the CMD.EXE-sessions with eCS 1.2.
    >
    > What can I do to compile LostKingdom.C, is this reveiling an ICC-bug or
    > am I just showing a problem with regads to my level of patience?
    >
    > Please note it's a kind of "stress test". I think it should work and it
    > should be compilable within a reasonable period of time, without any
    > ICC-switches, like the Mandelbrot-example.
    >
    >

    I compiled with:

    IBM VisualAge C++ for OS/2, Version 3
    (C) Copyright IBM Corp. 1991, 1995.
    - Licensed Materials - Program Property of IBM - All Rights Reserved.

    21.10.98 3.08 41.984 0 a--- icc.exe

    and chose this commandline:
    icc.exe -Q+ -Fw- -O- -Gm+ -Ge+ -Gd- -Tl- -Ti+ -C+ -Fo+ lostkingdom.c
    and was able to produce an .obj file (with debug information).

    Then I ran:
    ilink.4b6 /NOL /DE /DB /Out:lostkingdom.exe /EXE /E:2 /PACKD /PACKC
    /STACK:0x30000 lostkingdom.obj
    to create an executable (with debug info)



    1.) You can use ILINK.STD or ILINK.4B6. However, the latest ILINK.EXE
    (version 5) will not be able to read the .obj file, at least not, if it
    contains debug info

    [D:\var\temp]ilink.std

    IBM(R) Linker for OS/2(R), Version 01.08.r1a_CTC308c
    (C) Copyright IBM Corporation 1988, 1997.
    (C) Copyright Microsoft Corp. 1988, 1989.
    - Licensed Material - Program-Property of IBM - All Rights Reserved.

    ILink : fatal error LNK1020: no object modules specified

    [D:\var\temp]ilink.4b6

    IBM(R) Linker for OS/2(R), Version 03.99.v4b6_970709
    Copyright (C) IBM Corporation 1988, 1997.
    Copyright (C) Microsoft Corp. 1988, 1989.
    All rights reserved.

    ILink : fatal error LNK1020: no object modules specified



    2.) You have to specify a stacksize of at least 0x30000. 0x10000 turns
    out to be too small.

    3.) Looks like it is close to impossible to enable the optimizer.


    Lars




  3. Re: VACPP 3.08-problem with large source file?

    [A complimentary Cc of this posting was NOT [per weedlist] sent to
    Lars Erdmann
    ], who wrote in article <4907a853$0$30224$9b4e6d93@newsspool1.arcor-online.net>:
    > I compiled with:
    >
    > IBM VisualAge C++ for OS/2, Version 3
    > (C) Copyright IBM Corp. 1991, 1995.


    I tried with gcc 4.3.2 (Oct 15), and got

    cc1plus: out of memory allocating 33554432 bytes after a total of 302120960 bytes

    Looks like gcc 4.3.2 is compiled without -Zhighmem...

    Hope this helps,
    Ilya

  4. Re: VACPP 3.08-problem with large source file?

    On 10/28/08 01:41 pm, A.D Fundum wrote:
    > All required files are in http://home.uni-one.nl/m1/BF2C.ZIP, 270 KB. A
    > working example is already included, reproducable with:
    >
    > BF2C.EXE Mandelbrot.BF> Mandelbrot.C
    > ICC Mandelbrot.C
    >
    > The same seems to fail with the largest known app, LostKingdom.BF. I've
    > no idea if the LostKingdom.EXE would work at all, but so far it seems I
    > cannot compile the file LostKingdom.C produced with BF2C.EXE.
    >
    > The file LostKingdom.C is also included and should be reproducable with
    > the customized BF2C.EXE:
    >
    > BF2C.EXE LostKingdom.BF> LostKingdom.C
    >
    > Is it compilable with other compilers? More important: ICC (3.08) seems
    > to hang. I haven't waited hours, but the session seems dead. Rebooting
    > is required to kill the CMD.EXE-sessions with eCS 1.2.
    >
    > What can I do to compile LostKingdom.C, is this reveiling an ICC-bug or
    > am I just showing a problem with regads to my level of patience?
    >
    > Please note it's a kind of "stress test". I think it should work and it
    > should be compilable within a reasonable period of time, without any
    > ICC-switches, like the Mandelbrot-example.
    >
    >


    I compiled it with GCC-3.3.5 with gcc LostKingdom.c. It took at least 20
    minutes and used at least 600 MBs of memory (I had a nap while waiting)
    I doubt it would be compilable with VACPP or any other compiler built
    without high memory support though your icc should of crashed rather
    then freeze when out of memory.
    Note that most of the time the CPU meter read close to zero, just the
    drive light was on and the swapfile grew to over 600 MBs.
    LostKingdom.exe seems to run fine and is a text adventure in the spirit
    of Zork etc
    CPU is a Athlon XP 2400 with 512 MBs of memory
    Dave

  5. Re: VACPP 3.08-problem with large source file?

    Then you should have a look at my other email. The only problem is to turn
    on optimization. But there is about nothing to optimize on this program
    anyway (in a sense, it is already optimal).

    Lars

    > I compiled it with GCC-3.3.5 with gcc LostKingdom.c. It took at least 20
    > minutes and used at least 600 MBs of memory (I had a nap while waiting)
    > I doubt it would be compilable with VACPP or any other compiler built
    > without high memory support though your icc should of crashed rather then
    > freeze when out of memory.
    > Note that most of the time the CPU meter read close to zero, just the
    > drive light was on and the swapfile grew to over 600 MBs.
    > LostKingdom.exe seems to run fine and is a text adventure in the spirit of
    > Zork etc
    > CPU is a Athlon XP 2400 with 512 MBs of memory
    > Dave




  6. Re: VACPP 3.08-problem with large source file?

    This gave the best results from a exe size point of view (only 790 kBytes):

    icc -Gd+ -Ge+ -Gm+ -Gi+ -Gp- -Oc+ -Q -B"/EXEPACK:2 /PACKC /PACKD
    /STACK:0x30000 /BASE:0x10000" lostkingdom.c

    By the way: if you use VAC, as first line of code you will need to add:

    setbuf(stdout,NULL);

    VAC fully buffers stdout but that behaviour is not the correct one for
    the given code (gcc uses line buffering per default which does not cause
    problems).
    Adding the above line of code will turn off buffering which is the best
    behaviour for this program (as it is doing trillions of calls to the
    putchar function). This could also be advantageous for gcc.


    Lars



    Lars Erdmann schrieb:
    > A.D Fundum schrieb:
    >> All required files are in http://home.uni-one.nl/m1/BF2C.ZIP, 270 KB. A
    >> working example is already included, reproducable with:
    >> BF2C.EXE Mandelbrot.BF > Mandelbrot.C
    >> ICC Mandelbrot.C
    >>
    >> The same seems to fail with the largest known app, LostKingdom.BF. I've
    >> no idea if the LostKingdom.EXE would work at all, but so far it seems I
    >> cannot compile the file LostKingdom.C produced with BF2C.EXE.
    >>
    >> The file LostKingdom.C is also included and should be reproducable with
    >> the customized BF2C.EXE:
    >>
    >> BF2C.EXE LostKingdom.BF > LostKingdom.C
    >>
    >> Is it compilable with other compilers? More important: ICC (3.08) seems
    >> to hang. I haven't waited hours, but the session seems dead. Rebooting
    >> is required to kill the CMD.EXE-sessions with eCS 1.2.
    >>
    >> What can I do to compile LostKingdom.C, is this reveiling an ICC-bug or
    >> am I just showing a problem with regads to my level of patience?
    >>
    >> Please note it's a kind of "stress test". I think it should work and it
    >> should be compilable within a reasonable period of time, without any
    >> ICC-switches, like the Mandelbrot-example.
    >>
    >>

    > I compiled with:
    >
    > IBM VisualAge C++ for OS/2, Version 3
    > (C) Copyright IBM Corp. 1991, 1995.
    > - Licensed Materials - Program Property of IBM - All Rights Reserved.
    >
    > 21.10.98 3.08 41.984 0 a--- icc.exe
    >
    > and chose this commandline:
    > icc.exe -Q+ -Fw- -O- -Gm+ -Ge+ -Gd- -Tl- -Ti+ -C+ -Fo+ lostkingdom.c
    > and was able to produce an .obj file (with debug information).
    >
    > Then I ran:
    > ilink.4b6 /NOL /DE /DB /Out:lostkingdom.exe /EXE /E:2 /PACKD /PACKC
    > /STACK:0x30000 lostkingdom.obj
    > to create an executable (with debug info)
    >
    >
    >
    > 1.) You can use ILINK.STD or ILINK.4B6. However, the latest ILINK.EXE
    > (version 5) will not be able to read the .obj file, at least not, if it
    > contains debug info
    >
    > [D:\var\temp]ilink.std
    >
    > IBM(R) Linker for OS/2(R), Version 01.08.r1a_CTC308c
    > (C) Copyright IBM Corporation 1988, 1997.
    > (C) Copyright Microsoft Corp. 1988, 1989.
    > - Licensed Material - Program-Property of IBM - All Rights Reserved.
    >
    > ILink : fatal error LNK1020: no object modules specified
    >
    > [D:\var\temp]ilink.4b6
    >
    > IBM(R) Linker for OS/2(R), Version 03.99.v4b6_970709
    > Copyright (C) IBM Corporation 1988, 1997.
    > Copyright (C) Microsoft Corp. 1988, 1989.
    > All rights reserved.
    >
    > ILink : fatal error LNK1020: no object modules specified
    >
    >
    >
    > 2.) You have to specify a stacksize of at least 0x30000. 0x10000 turns
    > out to be too small.
    >
    > 3.) Looks like it is close to impossible to enable the optimizer.
    >
    >
    > Lars
    >
    >
    >


  7. Re: VACPP 3.08-problem with large source file?

    On 10/29/08 10:46 am, Lars Erdmann wrote:
    > Then you should have a look at my other email. The only problem is to turn
    > on optimization. But there is about nothing to optimize on this program
    > anyway (in a sense, it is already optimal).
    >


    Yes, I saw your other post right after posting this. How much memory did
    VACPP use and was your computer usable while compiling?
    Dave

  8. Re: VACPP 3.08-problem with large source file?


    >> IBM VisualAge C++ for OS/2, Version 3


    > I tried with gcc 4.3.2 (Oct 15), and got


    > cc1plus: out of memory allocating 33554432 bytes after a total of
    > 302120960 bytes


    > Looks like gcc 4.3.2 is compiled without -Zhighmem...


    Thanks for trying with GCC. I never got to see such an error message
    with ICC. If using "-Zhighmem" is RFC #1, perhaps (FWIW) RFC #2 could
    be to (limit or) stop the optimizing if the result of optimizing is no
    *.EXE at all (or optimizing takes too long, "Are you sure (N/y)?").



  9. Re: VACPP 3.08-problem with large source file?


    > I compiled it with GCC-3.3.5 with gcc LostKingdom.c. It took at
    > least 20 minutes and used at least 600 MBs of memory (I had a nap
    > while waiting)


    Later I had a sleep while waiting, and after 7 hours ICC still seemed
    to behave the same way as after ~20 minutes. No sign of heavy usage of
    anything after a short period of time (CPU load 0.5-0.6%), the pc was
    usable all the time (Thinkpad T23, 1.2 GHz, 1 GB RAM, CONFIG.SYS not
    fine-tuned), ICC.EXE et all didn't respond to session killers, I didn't
    montior the momery, and ICC's output never got further than what was
    already displayed in the 1st second of it running. With the customized
    ICC-switches posted by Lars, ICC-switches, it indeed compiled within a
    reasonable period of time (using a slower pc).

    > your icc should of crashed rather then freeze when out of memory.


    Admitting it ain't a typical C app, no *.EXE is even too extreme when
    optimizing the size of the *.EXE.

    > Note that most of the time the CPU meter read close to zero


    Same here, 0-100% for less than 1 minute, AFAICT followed by close to
    zero.

    > just the drive light was on and the swapfile grew to over 600 MBs.


    Basicly I haven't seen the light, so I didn't get the impression there
    was a reason to look at memory-related signals. During earlier tests I
    executed "BF2C SmallApp.BF SmallApp.BF SmallApp.BF SmallApp.BF", and
    never saw any clue the optimizing of ICC was appox. exponential in
    procressing time/resource claims... :-|

    > LostKingdom.exe seems to run fine


    Not here, but Lars also pointed that out (different buffering of stdout
    with ICC versus GCC, I don't know about OW).

    > and is a text adventure in the spirit of Zork etc


    I cannot check it right now, but ISTR the first statement was bogus (or
    just making sure of a situation being right, just like "int x=0;x=0;"),
    so I didn't know for sure if it would work. It does work, and GCC shows
    the best results (error message during compile, no buffering problem).



  10. Re: VACPP 3.08-problem with large source file?


    > The only problem is to turn on optimization. But there is about
    > nothing to optimize on this program anyway (in a sense, it is
    > already optimal).


    The source code of LostKingdom, embedded in the following data file,
    sure does look about near-optimal: ;-)

    http://student.kuleuven.be/~m0216922/braincopter/lk.png

    Not aimed at an optimized *.EXE, BF2C already adds some optimization,
    without overdoing it. Its *.EXE's are about 40% faster than one-on-one
    translations to C. Excluding spaces in the *.C, and now also being able
    to compile LostKingdom.C with ICC, I still may be able to get rid of a
    few % of slowlyness and (more likely) a few % of *.C-bytes.

    E.g. w.r.t. the first 3 bytes of LostKingdom.BF, unneeded {}'s and a
    few "c[--p]++;"'s instead of "p--;c[p]++"'s. Being able to compile it,
    I'm slightly curious how it affects the results, that also compared
    with ICC's optimalizations. I hope next saturday indeed turns out to
    be a rainy day... :-)



  11. Re: VACPP 3.08-problem with large source file?


    > This gave the best results from a exe size point of view (only 790
    > kBytes):


    Mine's larger than yours! Just over 1 MB. But that's with an unupdated
    situation, basicly VAC 3.08 and eCS 1.2 out-of-the-box. A little bit
    over 1 MB with:

    > icc -Gd+ -Ge+ -Gm+ -Gi+ -Gp- -Oc+ -Q -B"/EXEPACK:2 /PACKC /PACKD
    > /STACK:0x30000 /BASE:0x10000" lostkingdom.c


    Thanks! I was hoping to avoid any of the above, just because it then
    tends to become BF2ICC instead of BF2C, and I didn't expect a problem
    with optimizing (no extreme activity, and the *.C isn't that large). O
    well, what looked like an ICC-bug now can become a documented feature,
    which doesn't apply to a typical (and rather small) *.BF-file.

    > By the way: if you use VAC, as first line of code you will need to
    > add:
    > setbuf(stdout,NULL);


    Right. In other apps I already spotted problems with the buffering, but
    I didn't see this one until I saw a "working" LostKingdom.EXE. I'll get
    rid of the "fflush(stdout);" near the end of each translated file, and
    replace it with one of those near the beginning. Again, thanks.



  12. Re: VACPP 3.08-problem with large source file?

    Dave Yeo schrieb:
    > On 10/29/08 10:46 am, Lars Erdmann wrote:
    >> Then you should have a look at my other email. The only problem is to
    >> turn
    >> on optimization. But there is about nothing to optimize on this program
    >> anyway (in a sense, it is already optimal).
    >>

    >
    > Yes, I saw your other post right after posting this. How much memory did
    > VACPP use and was your computer usable while compiling?
    > Dave


    icc -Gd+ -Ge+ -Gm+ -Gi+ -Gp- -Oc+ -Q -B"/EXEPACK:2 /PACKC /PACKD
    /STACK:0x30000 /BASE:0x10000" lostkingdom.c

    uses up 172 MB and leaves the system responsive. It creates the smallest
    executable for the given source file (maximum optimization fails, see
    below).

    icc -Gd+ -Ge+ -Gm+ -Gi+ -Gp- -O+ -Q -B"/EXEPACK:2 /PACKC /PACKD
    /STACK:0x30000 /BASE:0x10000" lostkingdom.c

    extremely slows down the memory growth (it allocates and deallocates
    memory back and forth) and takes > 12 min before it finally ends stating
    "lostkingdom.c(0:0) : fatal error EDC4004: Not enough memory is available."
    I have the impression that realloc is used and eventually the heap is
    fragmented too much.
    However the system stays responsive during that time.

    System: 2GB main memory, 1.66 GHz CPU



    Lars

  13. Re: VACPP 3.08-problem with large source file?

    On 10/30/08 01:41 pm, A.D. Fundum wrote:
    > > just the drive light was on and the swapfile grew to over 600 MBs.

    >
    > Basicly I haven't seen the light, so I didn't get the impression there
    > was a reason to look at memory-related signals. During earlier tests I
    > executed "BF2C SmallApp.BF SmallApp.BF SmallApp.BF SmallApp.BF", and
    > never saw any clue the optimizing of ICC was appox. exponential in
    > procressing time/resource claims... :-|
    >


    The biggest problem here is that I only have 512 MBs of memory. With a
    GB I'd expect results more like Lars.
    Haven't seen so much swapfile churning in a long time
    Dave

  14. Re: VACPP 3.08-problem with large source file?


    >> Yes, I saw your other post right after posting this. How much memory
    >> did VACPP use and was your computer usable while compiling?


    > icc -Gd+ -Ge+ -Gm+ -Gi+ -Gp- -Oc+ -Q -B"/EXEPACK:2 /PACKC /PACKD
    > /STACK:0x30000 /BASE:0x10000" lostkingdom.c


    > uses up 172 MB and leaves the system responsive.


    P3, 128 MB RAM, a lot of harddisk activity, compiling takes about 10
    minutes, system becomes less responsive after each compile (realloc()
    and the heap were mentioned earlier). P3, 320 MB RAM, compiling will
    take about 1 minute, no responsivity-related problem noticed.

    setbuf(stdout,NULL); slightly slows down output, I'll think about a
    check for getchar(), setbuf() basicly is required then. Otherwise a
    fflush() may be enough (or a timed fflush()-thread? I'll see).

    FWIW: the LostKingdom.EXE obtainable earlier probably won't work good
    and it'll require a "#define CELLTYPE short" or better. I saw a value
    >255, too large for a char and I don't think it's Fun by Design.


    Using "putchar(c[--p]);" instead of "p--;putchar(c[p]);" reduced the
    size of my LostKingdom.EXE from 1077 KB to 1075.5 KB, but so far other
    basic attempts to optimize the size resulted in an equal *.EXE combined
    with a smaller *.C source file.



  15. Re: VACPP 3.08-problem with large source file?

    On 11/04/08 10:03 am, A.D. Fundum wrote:
    > >> Yes, I saw your other post right after posting this. How much memory
    > >> did VACPP use and was your computer usable while compiling?

    >
    > > icc -Gd+ -Ge+ -Gm+ -Gi+ -Gp- -Oc+ -Q -B"/EXEPACK:2 /PACKC /PACKD
    > > /STACK:0x30000 /BASE:0x10000" lostkingdom.c

    >
    > > uses up 172 MB and leaves the system responsive.

    >
    > P3, 128 MB RAM, a lot of harddisk activity, compiling takes about 10
    > minutes, system becomes less responsive after each compile (realloc()
    > and the heap were mentioned earlier). P3, 320 MB RAM, compiling will
    > take about 1 minute, no responsivity-related problem noticed.
    >


    icc uses much less memory (at least with the above flags) then gcc 3.3.5.
    If I get time I'll experiment with some flags
    Dave

+ Reply to Thread