* begin/end reducing memory consumption?
@ 2012-06-22 9:08 Anonymous
2012-06-22 11:10 ` Georg Bauhaus
0 siblings, 1 reply; 3+ messages in thread
From: Anonymous @ 2012-06-22 9:08 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3190 bytes --]
Hi all,
I'm currently evaluating Ada as an alternative to C++ for scientific programming. I have a simple test program that within its main loop repeatedly calls the following procedure:
procedure Propagate is
Access_Temp : constant Access_Probability_Field
:= Access_New_Field;
begin
Access_New_Field.all := (others => (others => (others => 0.0)));
for Nx in -Fringe_Index .. Fringe_Index loop
-- Fringe_Index = about 50
for Ny in -Fringe_Index .. Fringe_Index loop
for Ntheta in Angle_Index'Range loop
-- Range = 0 .. 199
begin -- why do I need this?
for W of Weight_Vectors (Ntheta) loop
-- Weight_Vectors (Ntheta) is a Vector of type Ada.Containers.Vectors
-- (Element_Type => Weight, Index_Type => Natural), where Weight is defined as
-- subtype Pixel_Offset is Integer range -Max_Offset .. Max_Offset;
-- type Weight is record
-- Nx, Ny : Pixel_Offset;
-- W : Long_Float;
-- end record;
for D_Index in Angular_Propagator'Range loop
Access_New_Field
(Nx + W.Nx, Ny + W.Ny, Ntheta + D_Index)
:= Access_New_Field -- (Nx, Ny + 1, Ntheta)
(Nx + W.Nx, Ny + W.Ny, Ntheta + D_Index)
+ Access_Old_Field (Nx, Ny, Ntheta) * W.W
* Angular_Propagator (D_Index);
end loop;
end loop;
end;
end loop;
end loop;
end loop;
Access_New_Field := Access_Old_Field;
Access_Old_Field := Access_Temp;
end Propagate;
Access_New_Field and Access_Old_Field are of type access Probability_Field, where
type Probability_Field is array
(Pixel_Index'Range, Pixel_Index'Range, Angle_Index'Range)
of Long_Float;
subtype Pixel_Index is Integer range
-(Fringe_Index + Max_Offset) .. (Fringe_Index + Max_Offset);
my main loop looks like this:
Access_New_Field := new Probability_Field;
Access_Old_Field := new Probability_Field;
for K in 1 .. No_Iterations loop
Put_Line ("Iteration " & Integer'Image (K));
Propagate;
end loop;
What I don't get is that if I comment out the above "begin/end" lines,
then memory usage increases with No_iterations and for No_iterations = 8
reaches about 550 MB. Including begin/end reduces memory usage to 37MB (then independent of No_iterations, as it should be). For what it's worth, I'm using the following compiler flags (with GNAT GPL 2011 on Mac OS X 10.7.4, 2010 MacBook Pro):
gnatmake -o Main Main -P"/Users/sebastian/Documents/Studium/Research/hard-disk-disorder/lattice-propagator/release.gpr" -g -cargs -gnatq -gnatQ -bargs -largs
gcc -c -gnatQ -O3 -gnatp -gnat2012 -g -gnatq -gnatQ -I- -gnatA [�]/Main.adb
gcc -c -gnatQ -O3 -gnatp -gnat2012 -g -gnatq -gnatQ -I- -gnatA [�]/lattice_propagator.adb
gcc -c -gnatQ -O3 -gnatp -gnat2012 -g -gnatq -gnatQ -I- -gnatA [�]/geometry.adb
gnatbind -E -static -I- -x [�]/obj/main.ali
gnatlink [�]/obj/main.ali -g -o [�]/build/Main
Is this expected behaviour? If yes, could someone please explain what's going on internally?
Best regards,
Sebastian
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: begin/end reducing memory consumption?
2012-06-22 9:08 Anonymous
@ 2012-06-22 11:10 ` Georg Bauhaus
0 siblings, 0 replies; 3+ messages in thread
From: Georg Bauhaus @ 2012-06-22 11:10 UTC (permalink / raw)
On 22.06.12 11:08, Anonymous wrote:
> What I don't get is that if I comment out the above "begin/end" lines,
> then memory usage increases with No_iterations and for No_iterations = 8
> reaches about 550 MB. Including begin/end reduces memory usage to 37MB (then independent of No_iterations, as it should be).
This is mere speculation:
The block statement makes some variables "more" local
and the implementation of Vectors can perform some memory
management.
I'd try -O2 -funroll-loops [-gnatn], too, replacing -O3.
(Some oddly related information (or maybe not having something
to do with this at all) may be available if you have GCC
-fdump-tree-slp-details. I have seen some decisions reported
there to do with exceptions handling being obstacles;
that was FSF GNAT, though, GNAT GPL seemed "better", and
the issue might be gone with most recent FSF GNATs.)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: begin/end reducing memory consumption?
@ 2012-06-24 13:57 Nomen Nescio
0 siblings, 0 replies; 3+ messages in thread
From: Nomen Nescio @ 2012-06-24 13:57 UTC (permalink / raw)
> This is mere speculation:
> The block statement makes some variables "more" local
> and the implementation of Vectors can perform some memory
> management.
> I'd try -O2 -funroll-loops [-gnatn], too, replacing -O3.
> (Some oddly related information (or maybe not having something
> to do with this at all) may be available if you have GCC
> -fdump-tree-slp-details. I have seen some decisions reported
> there to do with exceptions handling being obstacles;
> that was FSF GNAT, though, GNAT GPL seemed "better", and
> the issue might be gone with most recent FSF GNATs.)
thanks, I tried that. Neither -gnatn, -O2 nor -O2 -funroll-loops resolved the issue, however.
-fdump-tree-slp-details generates a huge amount of what seems like potentially useful
information; however, the begin/end pair renames many variables (D.[some number] -> D.[some
number - 40] or so), so I don't get a useful diff without first changing back all those
identifiers; I'll try to do that later.
Anyway, what kind of memory management do we need
here? Except for the loop indices, I thought that the compiler shouldn't have to allocate any
variables at all. And even if it had to, shouldn't those be freed again after procedure
Propagate terminates?
best regards,
Sebastian
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-06-24 13:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-24 13:57 begin/end reducing memory consumption? Nomen Nescio
-- strict thread matches above, loose matches on Subject: below --
2012-06-22 9:08 Anonymous
2012-06-22 11:10 ` Georg Bauhaus
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox