[erlang-questions] Is it possible to align binary's byte array to cache line boundary?

max tan maxtqm@REDACTED
Sat Sep 17 18:30:48 CEST 2011


>
> On Thu, Sep 15, 2011 at 09:21, max tan <maxtqm@REDACTED> wrote:
> > It seems not supported in current VM, right?
>
> If it is supported, it will be automatic and done for all binaries.
> Take a look at the allocator used for allocation of binaries, since it
> is a different one than the one used for allocation of process heaps.
I saw in BEAM's sources, that when the binary's size is 64 bytes or less,
BEAM will allocate a ErlHeapBin on local heap,

    in "erl_binary.h":

      typedef struct erl_heap_bin {
          Eterm thing_word;		/* Subtag HEAP_BINARY_SUBTAG. */
          Uint size;			/* Binary size in bytes. */
          Eterm data[1];		/* The data in the binary. */
      } ErlHeapBin;



    in "binary.c":

      /*
       * Create a brand new binary from scratch.
       */

      Eterm
      new_binary(Process *p, byte *buf, Uint len)
      {
          ProcBin* pb;
          Binary* bptr;

          if (len <= ERL_ONHEAP_BIN_LIMIT) {
	      ErlHeapBin* hb = (ErlHeapBin *) HAlloc(p, heap_bin_size(len));
	      hb->thing_word = header_heap_bin(len);
	      hb->size = len;
	      if (buf != NULL) {
	          sys_memcpy(hb->data, buf, len);
	      }
	      return make_binary(hb);
          }

................


So, I can be sure that BEAM will align ProcBin instead of binary "data".
When len <= ( cache_line_size - sizeof(Eterm) - sizeof(Uint) ), it's OK,
the whole ProcBin can be fit in 1 cache line. Otherwise, for example when
len = cache_line_size, the whole ProcBin will surely span 2 or more cache
lines.

>
> Why do you need this guarantee?
>
For example, my application reads/creates/stores/sends binaries of
64 bytes repeatedly, if I can be sure that the binaries is allocated along
cache line boundary ( which is normally 64/128 byte multiplied ),  each
processing will need just 1 memory fetch, so cache-friendly, so I can
maximize the processing throughput.

>
> --
> J.



More information about the erlang-questions mailing list