unx86ing atomic functions

[tmagik]

The functions in util/atomic.* have a bunch of x86 assembly which is less than ideal on non-x86 hardware (like this 96 core arm64 I am playing with), and it would be nice to use some type of cross-platform atomic operations, either the ones provide in std::atomic, or a linux kernel vdso

[rescrv]

I agree that they are less than ideal. I have considered similar changes before (see Issue #19).

In this case, it's a little different because it opens up a new hardware platform. Inlined assembly is an important part of what makes things work. While I could fall back to slow primitives on non-x86, I would be hesitant to do this. Worse would be blindly adding the arm64 code to support your platform, because its visibility semantics are different enough from x86 that I'd want to personally test and verify the changes because the memtable---a piece critical to hyperleveldb's changes and most operations---relies heavily on these changes.

I assume you may have one of the System 76 servers. I've asked them about getting one to play with so I could support changes like this. Unfortunately, I'm not able to personally afford one of these servers. System76 didn't respond to my tweets, so I assume they either have no wiggle room and didn't want to disappoint or are disinterested in a one-off sale.

So while I'd love to support arm64, I cannot do so at this point.

I'll leave the issue open in case others want to chime in, or want to support me in purchasing such a server so I could port hyperleveldb to work on the platform.

[tmagik]

I'd send you some money for a day or two with https://www.packet.net/bare-metal/servers/type-2a/ (which is what I was using), or http://shop.technexion.com/wb-imx6q-bw.html if you want something more sustainable.

Then there is also PowerPC (IBM's Power9 is going to be pretty interesting), and Risc-V, which is going to get pretty interesting in a few years. To me, this seems like having a flag for either x86-asm, or C++11 atomics would be a potentially maintainable solution. I would then use the C++11 version on x86 even if the performance was a little worse

[rescrv]

I appreciate your perspective. I've talked with some people close to the RISC-V effort in the past and am looking at that architecture as well. PowerPC is less on my radar as IBM tends to be quite expensive.

For any of these architectures. there is a lot that needs to be tested. Using std atomics might work swimmingly, but then the OS might have problems. When I worked on Bitcoin's LevelDB bounty, the bug was related to the way the OS and LevelDB treated memory maps. It was not a bug likely to be triggered on Linux, and possibly is dependent upon the vmm subsystem's treatment of pages.

If you would like to fork this project to add std::atomics, I would happily update the readme to make people aware of the fork.

As it stands, my primary project is Consus, for which I will probably write a new backend. I would love to have a high-core-count server to test the project on where I have it persistently available to me for work. HyperLevelDB is not a priority for me and adding architectures and testing it will require quite a bit of time that I would rather allocate to other projects. If, however, I was able to get out of it some more resources to help with those other projects, I would be willing to put in the time and effort to make the changes. I appreciate your offer to donate some resources that would be sufficient to test the implementation. Unfortunately, it is a matter of both the resources and the time. Adding a persistent resource to my workflow would be a bonus worth the time it would take to support arm, and I was implying that's what I was trying to get out of System 76. Re-reading my above message makes it sound like it's only about the resources for this particular change and I'm sorry for the confusion.

[tmagik]

I am going to see if I can lean on Cavium get a ThunderX 1k reference board (48 cores). That would make up for the bad deal us engineers got in the acquisition.

Otherwise, I'm much more familiar with PowerPC assembly, and at some point I'm going to get a power8/power9 one way or another, and Consus would be a very interesting to see on whichever platform I end up with.

To fork for std::atomics, I would want to have a little better idea of what the x86 asm code does, and what might be different in the Arm/PPC relaxed memory model as compared to x86.