Re: [Caml-list] Bigarray question: Detecting subarrays, overlaps, ...

[Gerd Stolpmann <info@gerd-stolpmann.de>]

Am Mittwoch, den 29.02.2012, 10:23 +0100 schrieb Goswin von Brederlow:
> >> For efficiency each request stores all its data in a single
> >> Bigarray.Array1. For reasons of the RAID implementation large requests
> >> are split into 4k chunks using Bigarray.Array1.sub and grouped into
> >> stripes. The stripes are then acted upon independently until all stripes
> >> involved in a request are finished. Then the request is completed.
> >> 
> >> Now I get a problem when 2 requests come in that overlap. Say I get a
> >> write request for blocks 0 - 6 and a read request for blocks 4-9 in
> >> that order. Since I already have the data for block 4-6 in memory from
> >> the write request I do not want to reread them from disk. On the stripe
> >> level the data looks like this:
> >> 
> >> |W0 W1 W2 W3 W4 W5 W6 .  .  .  | write 0-6
> >> |            W4 W5 W6 R7 R8 R9 | read  4-9
> >> 
> >> For the read request I need to copy W4-6 to R4-6 or send out W4-6 + R7-9
> >> in two writes. I think I would like to avoid sending each stripe chunk
> >> out seperately.
> >
> > Why not? This seems to be an elegant solution, and I don't see why this
> > should make the accesses slower. The time for the extra context switches
> > in negligible compared to the disk accesses.
> 
> A lot of the time data will just move between caches so disk speed is
> secondary. And sending each chunk seperately would mean up to 32 context
> switches instead of 1. And writing to a socket in chunks can lead to the
> data being send out in frames less than the MTU which would be
> wastefull. So I think there is some gain in limiting this.

A context switch takes less than a microsecond on typical hardware,
including the time for rebuilding the TLB from the page table. Sending a
4K block over gigabit network takes more than 30 times longer. I doubt
you can gain from combining several chunks.

Sending the data in frames less than the MTU can normally only happen
when you disable the Nagle algorithm (did you?). And even then, you only
need to fill the TCP buffer faster than the network can transport the
data to avoid it. 

> >>  On the other hand I could implement (p)readv() and
> >> (p)writev() stubs.
> >> 
> >> Anyway, my question now is how to detect which subarrays in the stripes
> >> are part of a common larger array? Do I need to write my own C stub that
> >> looks into the internas of the arrays to see if they share a common
> >> ancestor?  I think that would be preferable to tracking the origin of
> >> each subarray myself.
> >
> > Yes, subarrays are tracked, but this feature exists only to catch the
> > right moment for unmmapping bigarrays (if needed). As far as I remember,
> > this is not tracked as a sub/super relationship, but the bigarrays
> > accessing the same buffer share then the same buffer descriptor, and
> > when the use count drops to 0, the buffer is finally destroyed. So, you
> > cannot say which bigarray is the original one, and it can even be that
> > the original bigarray is already deallocated but the backing buffer is
> > not yet.
> 
> All subarrays share a struct caml_ba_proxy, as you say to catch the
> right moment for unmmapping bigarrays. So two subarrays are part of the
> same bigarray if they have the same proxy object. That seems like an
> easy enough test. Which one is the original bigarray doesn't matter, at
> least to me.
> 
> >> On a similar note how does Bigarray.Array1.blit handle arrays that are
> >> part of the same larger array and overlap?
> >> 
> >> ----------------------------------------------------------------------
> >> I'm missing functions like:
> >> 
> >> val super : ('a, 'b, 'c) t -> ('a, 'b, 'c) t -> ('a, 'b, 'c) t
> >>     Create a merged sub-array of 2 adjacent sub-arrays of the same
> >>     big array.
> >
> > This function would be possible to implement. The requirement would be
> > that both bigarrays use the same buffer descriptor.
> >
> >> val same_parent : ('a, 'b, 'c) t -> ('a, 'b, 'c) t -> bool
> >>     True if the 2 (sub-)arrays are part of the same big array.
> >
> > I would not call it "same_parent", but "same_backing_buffer".
> 
> Maybe "related" would be better?
> 
> >> val offset : ('a, 'b, 'c) t -> int
> >>     Offset of the sub-array in the underlying big array.
> >
> > I think this information is in the current implementation not available.
> > As buffer sharing is also possible after reshaping, this is also not
> > meaningful in the general case.
> 
> offset = array->data - array->proxy->data;
> 
> After reshaping the offset would be the offset into the original array
> after reshaping that too.
> 
> For me the offset would be relevant to see which 2 sub arrays could be
> merged with "super" above. That it wouldn't always be meaningfull I
> could accept.

What I did not understand up to now: It is really easy to keep all this
information in a helper data structure. Why extend Bigarray?

Gerd

> 
> > Gerd
> 
> MfG
>         Goswin
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.
------------------------------------------------------------