On Thu, 2013-11-28 at 17:19 +0000, David Koontz wrote:
> Using Nick's test bench I successfully ran the fsm model unchanged.
> It peaked at 630 MB memory utilization.
>
> ghdl -r fsm_test --stop-time=100ns
>
> Has a 10 ns clock period so 10 clocks. Reset released after 50 ns,
> all inputs set to '0'.
>
> This on a Mac, a ghdl_mcode version. Peak Memory determined by the
> Activity Monitor Memory pane (OS X 10.9), ran twice.
>
> From which I can conclude Adrien was definitely out of memory, my Mac
> had over 2.7 GB free when I ran it. I figured it would work when I
> saw Adrien's messages didn't concern stack sizes.
More data points.
Here (on a 64-bit Linux build of ghdl-0.31dev) I see:
Allowing 3GB, 3.5, 4, 4.5GB and unlimited...
ulimit -v 3000000
ghdl -a fsm.vhd
virtual memory exhausted: Cannot allocate memory
ghdl: compilation error
ulimit -v 3500000
ghdl -a fsm.vhd
ghdl1: out of memory allocating 134217728 bytes after a total of
472821760 bytes
ghdl: compilation error
ulimit -v 4000000
ghdl -a fsm.vhd
ghdl1: out of memory allocating 4064 bytes after a total of 820473856
bytes
ghdl: compilation error
ulimit -v 4500000
ghdl -a fsm.vhd
ghdl1: out of memory allocating 33554432 bytes after a total of
1160146944 bytes
ghdl: compilation error
(no ulimit)
ghdl -a fsm.vhd
and GHDL runs its memory use to 4.8GB at which point my 4GB machine is
swapping. After about 10 minutes with everything else closed down, I
killed it.
Now if the mcode version compiles fsm.vhd just fine, this is pointing to
the gcc middle and back end...
Searching for the messages shows
gcc/ggc-page.c: perror ("virtual memory exhausted");
libiberty/xmalloc.c: "\n%s%sout of memory allocating
%lu bytes after a total of %lu bytes\n",
And reading around, the gcc middle and back ends are notoriously memory
hungry, as they run many (typically hundreds of) optimisation passes.
I tried unsuccessfully to pass -O0 flags on the command line, to see if
it used less memory with optimisation off.
ulimit -v 4000000
ghdl -a -O0 fsm.vhd
ghdl1: out of memory allocating 48 bytes after a total of 820453376
bytes
So I think this one is worth reporting on
https://gna.org/bugs/?group=ghdl
with the note that the mcode version bypasses gcc's memory-hungry
optimisation passes.
(Makes me wonder if it's possible to build the mcode version on Linux?)
Now the other example appears to elaborate successfully
ghdl -a tb.vhd
but the alleged problem is that it fails with "(others => (others =>
'0')) to initialise ... I'm not clear ... is this right?
constant in_vectors : invec_type;
constant out_vectors : outvec_type;
My problem with that file is that the current initialiser for
out_vectors is an aggregate on a single line, 2588734 characters long!
My text editor won't display it! I tried pasting it into my email client
and had to kill/restart it! So I have my doubts whether ghdl isn't
perhaps truncating it or (unlikely) failing and exiting silently.
I would like to see this file recreated with a more sane line length.
- Brian
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
