aligned memory to 4096

[hmaarrfk]

I've found that in many cases aligning memory to 4096 is really beneficial especially when writing large (>1MB) files to disk.

Is this something you would consider?

The implementation might look something like:

diff --git a/src/core/others/ojph_file.cpp b/src/core/others/ojph_file.cpp
index d4a4756..359e088 100644
--- a/src/core/others/ojph_file.cpp
+++ b/src/core/others/ojph_file.cpp
@@ -43,6 +43,8 @@
 #include <cassert>
 #include <cstddef>
 
+#include <malloc.h>
+
 #include "ojph_file.h"
 #include "ojph_message.h"
 
@@ -110,7 +112,11 @@ namespace ojph {
   mem_outfile::~mem_outfile()
   {
     if (buf)
+#ifdef OJPH_OS_WINDOWS
+      _aligned_free(buf);
+#else
       free(buf);
+#endif
     is_open = clear_mem = false;
     buf_size = used_size = 0;
     buf = cur_ptr = NULL;
@@ -198,15 +204,26 @@ namespace ojph {
   /** */
   void mem_outfile::expand_storage(size_t needed_size, bool clear_all)
   {
+    auto new_buf = this->buf;
     if (needed_size > buf_size)
     {
       needed_size += (needed_size + 1) >> 1; // x1.5
       si64 used_size = tell(); // current used size
 
-      if (this->buf)
-        this->buf = (ui8*)realloc(this->buf, needed_size);
-      else
-        this->buf = (ui8*)malloc(needed_size);
+#ifdef OJPH_OS_WINDOWS
+      new_buf = (ui8*)_aligned_alloc(4096, needed_size);
+#else
+      new_buf = (ui8*)aligned_alloc(4096, needed_size);
+#endif
+      if (this->buf != new_buf && !clear_all){
+        memcpy(new_buf, this->buf, used_size);
+#ifdef OJPH_OS_WINDOWS
+        _aligned_free(this->buf);
+#else
+        free(this->buf);
+#endif
+      }
+      this->buf = new_buf;
 
       if (clear_mem && !clear_all) // will be cleared later
         memset(this->buf + buf_size, 0, needed_size - this->buf_size);

I'm about to test building on all platforms, but I was wondering if that was something you might want to upstream.

Let me know.

[aous72]

Hi Mark,

Thank you for the suggestion.

In my code, I did not use any aligned memory allocation, because this has limited support.
There is
_aligned_malloc in windows
aligned_malloc in Linux
posix_memalign
and not all platforms support them.

When I need aligned allocation, I allocate a few more bytes than what I need, and then use memory at an aligned starting address within the allocated buffer.

If you really want to improve performance, consider using low-level IO, but again this will be platform dependent.

I am rather uninterested -- I am really sorry.

Kind regards,
Aous.

[hmaarrfk]

The performance difference can be quite stark between arrays aligned to 4096 and those that are not.

When communicate with PCIe peripherals, the driver code will essentially use bounce buffers if things are not aligned and locked.

Would you consider adding a compilation flag? Basically, I can write to your mem_our file implementation then copy it to disk very fast if it is aligned. Otherwise data copies will be made losing on much of the performance and multi threaded potential.

If you want a full benchmark, that would take me more time.

[aous72]

OK, Mark. You seem very keen.

Could you define a function, like ojph_aligned_malloc and ojph_aligned_free and put your definition inside them? Perhaps at the top of ojph_file.h, like I am doing with ojph_fseek and ojph_ftell, to hide the platform dependency. Then you can call this function from elsewhere.

It would be nice to have normal malloc and free as a fallback strategy when no platform can be identified, If the code can be arranged this way.

It is not clear to me where to put the POSIX version, but it is ok to leave it out.

It would be nice to have benchmarks if they are handy or done by someone else -- I do not want you to spend time to generate them.

I am also wondering if the issue is really how C++ library handles file buffering; it uses a rather small temporary buffer, which might not be ideal.
It is also conceivable that, if you are writing a large amount of data, to write the first non-aligned section (less than 4K to bring it to the boundary of 4K), followed by what is left of the file which should be aligned.

Kind regards,
Aous.

[aous72]

I think ojph_mem.h is better.

[hmaarrfk]

OK, Mark. You seem very keen.

I should really write a paper about this since I think it is really not obvious how to achieve sustained 5GB/s operation from a single SSD which we routinely do, from within python. I'm talking about TB of data both read and written.

It would be nice to have benchmarks if they are handy or done by someone else -- I do not want you to spend time to generate them.

Its pretty easy for me to write them in Python. If you are comfortable reading it. Writing it in C++ will be slower for me. However the python calls used to acheive performance basically call down to the linux system calls.

All my benchmarks focus on Linux operation.

I think MacOSX and windows can likely mimic the operations, but yeah, I'm just not so focused on those beyond ensuring basic compatibility.

It is also conceivable that, if you are writing a large amount of data, to write the first non-aligned section (less than 4K to bring it to the boundary of 4K), followed by what is left of the file which should be aligned.

This doesn't really work since the requirement is that you must have both the source and the destination be aligned to 4k.
This is where a short 1-2 page paper about this might be interesting.

[shuffle2]

if you just want nicer code to create aligned allocations, just bump c++ std version and use std::aligned_alloc?

getting windows to issue nvme dma directly to userspace buffers isn't that hard, no idea if the openpjh path triggers it tho.

[aous72]

Hi @shuffle2,

Thank you for the feedback and the pointer.
I was thinking of keeping everything to C++11; then I used google gtest, which requires C++14. I still aspire to have everything in C++11..

For most of the program, I allocate more than I need, then I choose a buffer start pointer that has the desired alignment (using an address larger than the address returned by malloc). Note that sometimes I need the second entry of the buffer to be aligned, not the first.

The issue with 4096 alignment is that I need to allocated 4095 extra bytes to do my trick, and I felt that this might be too much.

getting windows to issue nvme dma directly to userspace buffers isn't that hard, no idea if the openpjh path triggers it tho.

Any benchmarks for that, any more information will be useful for me and @hmaarrfk.

Kind regards,
Aous.