Dear All,
I've played around with the heat example provided in the tutorial.
However, when I increased the domain size from 8 by 16 to
const unsigned int vec_height = 1024;
const unsigned int vec_width = 1024;
const unsigned int vec_size = vec_height * vec_width;
and remove the output at the end, I get segmentation faults.
Any Ideas?
I also forgot to mention that
I also replaced with .
DDD points to a problem with line 117.
Dense vec_grid;
Wim
Hello Wim, we discovered the issue with the heat diffusion at about the same time you did. We are giving a tutorial at SuperComputing 2010 today with an *updated* Heat Diffusion example and code taking this into account. I will send it to you and the forum as soon as we have it in a nice packaged form for everyone to download.
Thanks,
I played around this afternoon with the environmental variables
like ARBB_INIT_HEAP and others documented here.But no change in behavior.
When I turned on ARBB_VERBOSE=1, I saw that there is also a scalar HEAP.
Is there a environment variable to change its size?
Just a small comment, posting our updated version of the heat diffusion still means we are going to resolve the underlying issue.
Hello Wim,
adjusting ARBB_INIT_HEAP etc. would influence the initial size of the heap to draw from this pool during allocation of containers or scalar data. As you already noticed these pools might be separated between scalar data and container data. I would recommend to just stick with the defaults values. Do you have a specific issue which makes you thinking about an adjustment? Actually, the environment option setting this initial heap size doesn't mean that the memory consumption is prevented to grow as necessary.
Hey,
Many thanks for your replies.
I was testing the cache behavior of ArBB with large domains. As you know
stencil computations have a terrible arithmic intensity, which is the ratio of flops
to memory reads from slow memory. I wanted to see what happened if the domain did not fit in any of the levels of the cache hierarchy. This typically kills the speed of an applications since the performance is then bounded by the memory bandwidth.
I just noticed that the domain I was using was about the size of the scalar heap.
I used, in one of the tests, a domain of 1024 by 1024 doubles, both for swap and grid, the dense containers. This gives about the default memory allocated for the scalar heap. This just appeared odd to me.
But it turns out to be a coincidence, I also got into trouble for smaller domains.
I am new to ArBB and I am trying to learn this stuff. I really like the approach and many thanks for making this available.
Wim
Replacing
ARBB_CPP_ALIGN(priT grid[vec_size]);
ARBB_CPP_ALIGN(priT swap[vec_size]);
with
priT *grid= (priT*)(arbb::aligned_malloc( vec_size*sizeof(priT)));
priT *swap= (priT*)(arbb::aligned_malloc( vec_size*sizeof(priT)));
solves the problem.
It also gives some nice performancs for 8000 by 8000 domains.
Wim