- Performance of unaligned memory-accesses - 19 Updates
- Here is my new variants of Scalable RWLocks that are powerful.. - 1 Update
- In the end, rason will come - 2 Updates
| David Brown <david.brown@hesbynett.no>: Aug 07 09:32PM +0200 On 07/08/2019 18:33, Bonita Montero wrote: >> Any code that relies on this is very badly written. > Depends on which platforms you target. No, it does not - unless you a programming for a single compiler and single target for which the compiler documentation clearly says that unaligned accesses are supported. Even then, you will usually need to do something special (like using the "__unaligned" modifier with MSVC). > with special alignment-directives or with pointer-casting. So these > developers that use unalignes acesses know what they're doing and > they know the target-platforms. If they use pointer casts to break alignment requirements (or access objects through incompatible types), then clearly they /don't/ know what they are doing as this is very specifically not allowed by the language. > Maybe it will break because of other features; but the unaligned > themselfes accessses are mostly de-facto-portable to the target > -platforms. No, they are not. You are extrapolating from "it seemed to work when I tried it on one compiler without optimisation" to "it works everywhere". That is ridiculous. It is downright scary that someone who thinks of themselves as a serious programmer would write such stuff. >> know the OS will trap unaligned accesses and emulate them in software? > It's just a tiny task to support this by an OS and helps to run a lot > of old code; so this is very likely. You have /no/ concept of what you are talking about. And you have made it perfectly clear that you have no reference or samples - you are making up stuff as you go along. > My statement was related to your taste of proper programming and not > to the standard. > You're simply one of those compulsive and intolerant programmers. I have little tolerance for people who write code that they know is bad. I have no tolerance for people who not only insist that it is good code on their one platform, but think that this means it works everywhere. You appear to have a very serious misunderstanding of how programming and languages work. Understanding the language and writing code that is correct and valid is not a matter of taste. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 07 07:48PM On Wed, 2019-08-07, David Brown wrote: > others, various things could happen. On big OS's, you are likely to get > a trap or exception causing the OS to kill your program with a fault - I > can't imagine why an OS would bother simulating the unaligned access. Somewhere in my career I saw some system do that simulation. I can't remember where, but I think we disabled the feature after a while, when we saw it caused a lot more problems than it solved (broken programs would slow down to a crawl instead of crashing and thereby telling us they were broken). I think it was an ARM of some kind. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Christopher Collins <ccollins476ad@gmail.com>: Aug 07 12:50PM -0700 > There is rarely any reason for wanting unaligned access, and no > justification for using it in code that should be portable. There is one good reason for wanting it: reduced code size. If you are willing to tie yourself to gcc or clang (and probably others), you can annotate struct definitions with `__attribute__((packed))`. Then you don't need to manually [un]marshal objects that get sent over the network. If the processor does not support unaligned accesses, then the compiler has to generate the marshalling code, and there is probably no savings in code size. But for processors that support fast unaligned access (e.g., ARM cortex M4), the compiler just pretends the data is aligned. You don't pay the price in code size for [un]marshalling code, and the C code is considerably simpler. [...] Chris |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 07 07:58PM On Wed, 2019-08-07, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: ... > methods used on Intel processors if they want to gain any market share > since most of the software would be ported from X86. That means things > like unaligned accesses Why would they want that to work? With C or C++ code you can only provoke an unaligned access by writing broken code. Also, the huge body of Unix software is already free from such code (or it wouldn't have worked on e.g. SPARC or PPC). > and providing something that looks like the intel strongly (program) > ordered memory model are high on the desirable feature list. That I can believe, since most people didn't play with such things until long after x86 won dominance. I've written (and been told to write) application code which relied on the x86 model in that area. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 07 10:01PM +0200 > single target for which the compiler documentation clearly says that > unaligned accesses are supported. Even then, you will usually need to > do something special (like using the "__unaligned" modifier with MSVC). No, you don't have to program for a single computer / compiler, but you can do that for multiple platforms if you have their capabilities in mind > If they use pointer casts to break alignment requirements (or access > objects through incompatible types), then clearly they /don't/ know what > they are doing as this is very specifically not allowed by the language. They know what they do since they know their platform. >> themselfes accessses are mostly de-facto-portable to the target >> -platforms. > No, they are not. You have to kow the target-platforms. > You are extrapolating from "it seemed to work when I tried it on one > compiler without optimisation" to "it works everywhere". I never said that. I said that you usually have a set of target-patforms that allow unaligned accesses. > You have /no/ concept of what you are talking about. And you have made > it perfectly clear that you have no reference or samples - you are > making up stuff as you go along. No argumentation against what I said above. > I have little tolerance for people who write code that they know is bad. IF the discussed codig is bad depends on the target-platform. Usually it will work because either the CPU supports that or the operating-sys- tem traps unaligned accesses; but in the latter case it's very slow and that's just for compatibility and it's not recommended to rely on it for code that has to run fast. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 07 10:08PM +0200 > Why would they want that to work? With C or C++ code you can only > provoke an unaligned access by writing broken code. It's only broken in theory. In reality it will work on most platforms, although it might not be recommended on those emulating ualinged loads / stores through trapping because that's slow. > Also, the huge body of Unix software is already free from such code > (or it wouldn't have worked on e.g. SPARC or PPC). Linux onj SPARC f.e. emulates unaligned memory-accesses through trapping. With Solaris it depends on how you compile your code. |
| David Brown <david.brown@hesbynett.no>: Aug 07 10:13PM +0200 On 07/08/2019 21:58, Jorgen Grahn wrote: > provoke an unaligned access by writing broken code. Also, the huge > body of Unix software is already free from such code (or it wouldn't > have worked on e.g. SPARC or PPC). I suppose there are a few things to consider here. One is that C and C++ are not the only languages around - perhaps other languages allow unaligned access as long as the target supports it. The other is that, unfortunately, the programming world is full of people who don't know what they are doing, and there is a lot of badly written code out there. I guess the hardware folks would rather support this broken code than limit their market to higher quality code. > That I can believe, since most people didn't play with such things > until long after x86 won dominance. I've written (and been told to > write) application code which relied on the x86 model in that area. Certainly strong memory models can be easier to program than weaker ones. |
| scott@slp53.sl.home (Scott Lurndal): Aug 07 08:16PM >> Aarch64 was specifically designed as a server-capable processor. >> I was there. >All attempts to establish Aarch64-based machines as servers failed. And again, you are incorrect. https://www.cray.com/blog/inside-isambard-worlds-first-production-arm-supercomputer/ https://www.nextplatform.com/2017/11/13/cray-arms-highest-end-supercomputer-thunderx2/ There are also various cloud deployments. >F.e. this here: https://en.wikipedia.org/wiki/Calxeda Calxeda was using large arrays of A9's (32-bit processors). >And I doubt that Aarch64 was designed mainly with servers in mind. As I said, I was there. |
| David Brown <david.brown@hesbynett.no>: Aug 07 10:18PM +0200 On 07/08/2019 21:50, Christopher Collins wrote: >> There is rarely any reason for wanting unaligned access, and no >> justification for using it in code that should be portable. > There is one good reason for wanting it: reduced code size. Nope. Write your code properly and safely (using shifts and masks, memcpy, or compiler-specific features or intrinsics) and let the compiler turn it into unaligned accesses. Writing safe, correct, and valid source code is the programmer's responsibility. Turning it into small and fast object code is the compiler's responsibility. Don't try to do the compiler's job - work with it so that it can to the best job it can. > access (e.g., ARM cortex M4), the compiler just pretends the data is > aligned. You don't pay the price in code size for [un]marshalling code, > and the C code is considerably simpler. Compiler extensions like "packed" are fine in my book. Use them if they make the code clearer and more efficient - assuming, of course, that the lack of portability is not a problem. Compilers that don't support such features will complain, so you don't get silent problems. |
| "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Aug 07 01:37PM -0700 On 8/7/2019 12:52 AM, Bonita Montero wrote: > > algorithms that can use this. Although, FlushProcessWriteBuffers > > can work okay. > Do you have a link? The following link mentions the asymmetric Dekker algorihtm: https://blogs.oracle.com/dave/qpi-quiescence https://cdn.app.compendium.com/uploads/user/e7c690e8-6ff9-102a-ac6d-e4aebca50425/1a6535a9-5fe4-418b-ab11-91f1668a5720/File/acfe7384038ac881c1a34cc0cb0b9315/asymmetric_dekker_synchronization_140215.txt The short version: https://preview.tinyurl.com/y4e5forx There is biased locking: https://blogs.oracle.com/dave/biased-locking-in-hotspot One can remove the nasty #StoreLoad membar in hazard pointers: https://patents.google.com/patent/US20040107227A1/en This requires a store load relationship that even Intel does not have. An MFENCE or LOCK RMW is required. Acquiring a hazard pointer basically involves a load, store, load, compare, conditional loop. The store needs to be _before_ the following load. A release membar is not good enough, even on Intel. Keep in mind that Intel can reorder a store followed by a load to another location. http://www.cs.cmu.edu/~410-f10/doc/Intel_Reordering_318147.pdf |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 07 10:42PM +0200 >> All attempts to establish Aarch64-based machines as servers failed. > And again, you are incorrect. > https://www.cray.com/blog/inside-isambard-worlds-first-production-arm-supercomputer/ https://www.nextplatform.com/2017/11/13/cray-arms-highest-end-supercomputer-thunderx2/ We were talking about servers. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 07 10:48PM +0200 Consider this code. It compiles on whether certain platforms support unaligned loads with proper code and without vaguely relying on the compiler to strip away the assembly of a uint32_t with shifts and ORs with a single load / store. #include <cstdint> #ifdef _MSC_VER // MSC only works on x86/x64 and ARMv8 #define SUPPORTS_UNALIGNED #elif(__GNUC__) #if defined(__x86_64__) || defined(__i386__) #define SUPPORTS_UNALIGNED #elif defined(__aarch64__) #define SUPPORTS_UNALIGNED 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment