[MINC-users] MINC 2 api and RAM/HD access

[Soren Christensen]

Thanks to all!
>From local drive a call to miget_voxel_value_hyperslab takes me about
500ms - that is for a 512*320*12 short buffer lookup from the 512 512
320 12 matrix. This is noticeable and I am looking for half of that.
 Interestingly putting it in /dev/shm seems to make no difference. I
suppose the OS may be caching the file in RAM even if it is on the
drive?
The file is not compressed so nothing to gain for me here unfortunately.

The only thing I can thing of to speed it up further, is if the
reordering can be optimized - I suppose for certain reorderings longer
blocks can be copied at once, but this may be exploited already and I
am not even sure if there is any gain to be won here - any ideas on
this?

(The t-x-y lookup is 3ms, the t-x-z 252ms and finally t-z-y  is 519ms.
I assume y-z-t is the slowest since there is a jump for every voxel
read, whereas the two other "views" have larger continuous memory
blocks - can anyone confirm?)

Thanks again,
Soren







On Fri, Sep 14, 2012 at 7:21 AM, Andrew Janke <a.janke at gmail.com> wrote:
> I'll second this. The advantage is that you let the kernel do all the
> hard stuff.
>
>
> a
>
> On 13 September 2012 17:35, jon pipitone <jon.pipitone at utoronto.ca> wrote:
>> One far less glamorous way we've dealt with improving access speeds is to
>> move images onto a ramdisk (e.g. /dev/shm) and manipulate them there
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users