undefined | Better HN

0 pointsvardump7y ago0 comments

C alone doesn't provide the control directly, but you as a programmer can absolutely leverage C to take control of the memory hierarchies by controlling your data access patterns. IOW, high locality of reference.

Good C-compilers will most of the time take care of the superscalar CPU friendliness. When they don't, you can always drop down to the assembler level, and it'll mesh well with C.

0 comments

willtim7y ago

High-locality of reference can be achieved in any language that supports unboxed types, it doesn't require C (even a very high-level language like Haskell has support for this). But this is a long way from having complete control how each memory heirarchy is used.

Likewise most static languages defer to the compiler for CPU-specific performance optimisations and will permit foreign native calls into C or ASM where necessary. So I don't see how this is an argument in C's favour.

vardumpOP7y ago

> High-locality of reference can be achieved in any language that supports unboxed types, it doesn't require C (even a very high-level language like Haskell supports this).

You often also need correct alignment. Cache-line or page. Your unboxed access across two pages can cause two TLB misses, L1 misses etc. Not to mention two page faults.

Sometimes you need to ensure two (or more) buffers are NOT aligned in a particular way to avoid interfering with CPU caching mechanisms.

willtim7y ago

The only support C is giving you for this is that it has sized unboxed types (and raw pointer access). Even then, you'd have to trust the compiler and take measurements to be sure.

unwind7y ago

That's not true, since C11 we have:

    #include <stdlib.h>

    void *aligned_alloc(size_t alignment, size_t size);

which works like malloc() but lets you specify the required alignment.

2 more replies

vardumpOP7y ago

That's not true. You can also control data alignment in various ways. For example, you don't need to write to the beginning of an allocated buffer, but skip to the point where low order address bits are what you want.

Something like this for example:

  char* aligned_buf;
  char* buf;
  size_t max_align_offset = (1<<align) - 1;
  buf = malloc(length_needed + max_align_offset);
  aligned_buf = (buf + max_align_offset) & ~max_align_offset;

In the example, if align==8, you have 256 byte alignment. If it's 12, 4kB alignment.

2 more replies

j / k navigate · click thread line to collapse

0 comments

willtim7y ago

vardumpOP7y ago

> High-locality of reference can be achieved in any language that supports unboxed types, it doesn't require C (even a very high-level language like Haskell supports this).

You often also need correct alignment. Cache-line or page. Your unboxed access across two pages can cause two TLB misses, L1 misses etc. Not to mention two page faults.

Sometimes you need to ensure two (or more) buffers are NOT aligned in a particular way to avoid interfering with CPU caching mechanisms.

willtim7y ago

The only support C is giving you for this is that it has sized unboxed types (and raw pointer access). Even then, you'd have to trust the compiler and take measurements to be sure.

unwind7y ago

That's not true, since C11 we have:

    #include <stdlib.h>

    void *aligned_alloc(size_t alignment, size_t size);

which works like malloc() but lets you specify the required alignment.

2 more replies

vardumpOP7y ago

Something like this for example:

  char* aligned_buf;
  char* buf;
  size_t max_align_offset = (1<<align) - 1;
  buf = malloc(length_needed + max_align_offset);
  aligned_buf = (buf + max_align_offset) & ~max_align_offset;

In the example, if align==8, you have 256 byte alignment. If it's 12, 4kB alignment.

2 more replies

j / k navigate · click thread line to collapse