|
| I dont think fixed component dimensions would work. The problem that I
showed was just a simple analog. I am doing something more complicated.
Just in case someone has ideas on how to do this one, let me
mention what I want to do. Briefly, I will be having a simulation domain
with N_particles. This simulation domain will be divided into
N_cells with each cell containing (N_particles_cell) particles. Most
of the steps in the simulation would be limited to operating on particles
residing in a cell. # of Operations involving inter-cell communication
between data in two different cells is much smaller. So, I am trying to
fit all data related to a cell within cache.
I basically wanted to define a derived type like "cell_data" which would
contain all data related to the cell
type cell_data
integer :: cell_volume
integer :: No_of_particles_in_cell ! (which varires as the simulation
proceeds)
integer, dimension(:), allocatable :: list_of_particles_in_cell
! size of array will be (max_allowed_no_of_particles_in_cell)
real, dimension(:,:), allocatable :: position_particles
! size of array will be (no_of_dimensions, max_allowed_no_of_particles_in_cell)
real, dimension(:,:) :: velocity_particles ! same size as above
end type cell_data
type(cell_data), dimension(:) :: cells
allocate (cells(N_cells))
max_allowed_no_of_particles_in_cell are all determined by user input and
so I cant have fixed size arrays. Now, I would like to fit all data in
cells(cell_no=1) in the cache so that computations on cell_no 1 proceeds
really fast.
-shriram
> Shriram Ramanathan <ramanath@cems.umn.edu> wrote:
>
>
> Well, I mentioned a couple of methods. I spelled out one in code, but I
> mentioned several. One of them does - that's the method (also mentioned
> by Joe, with sample syntax shown) of making the component dimensions
> fixed size (presumably 3). I didn't hear an answer to the question of
> whether the fixed size would work for you. If a fixed size does work,
> then I'd strongly recommend it. It is fundamentally simpler. And yes, it
> guarantees contiguity (not quite in so many words in the standard, but
> close, and certainly in practice).
>
> The methods that involve allocatable or pointer components do not
> guarantee that. Indeed, they pretty much guarantee the opposite. The
> actual data array for an allocatable or pointer component is going to be
> at some other location in memory, separate from that of any other
> components. One could manage to force contiguity with pointers, but it
> would be a mess (allocate a large target array elswehere and make all
> the pointers point into areas of it that you parcel out); you'd have to
> have really good reason to do that. And you'd have good chance of
> hurting rather than helping performance because of pointer aliasing
> isssues.
>
>
|
|