Wilco (Wilco.Dijkstra@ntlworld.com) on 1/13/11 wrote:
---------------------------
>Megol (golem960@gmail.com) on 1/13/11 wrote:
>---------------------------
>>Wilco (Wilco.Dijkstra@ntlworld.com) on 1/12/11 wrote:
>>---------------------------
>>>Michael S (already5chosen@yahoo.com) on 1/12/11 wrote:
>>>---------------------------
>>>>Wilco (Wilco.Dijkstra@ntlworld.com) on 1/12/11 wrote:
>>>>---------------------------
>>>
>>>>[If the rumors are right and Microsoft indeed finishing porting of their Nt-based
>>>>line to ARM], I see close to zero chance that they will set SCTLR.A=1.
>>>
>>>Indeed. Note booting NT on ARM has been a compiler checkin requirement for a long time...
>>>
>>>>>So an ARM compiler will use LDM or LDRD
>>>>>only if the access is guaranteed (by the ABI) to be least 4-byte aligned. For badly
>>>>>written software which doesn't understand alignment at all, I added a mode in the
>>>>>ARM compiler which assumes all accesses are unaligned.
>>>>>
>>>>>Wilco
>>>>
>>>>Why do you call it badly written?
>>>>In my book the software does not have to be portable to be considered well-written.
>>>
>>>Writing software without considering portability is just madness, it doesn't take
>>>much extra effort, and I'd argue that anyone who doesn't understand portability
>>>shouldn't really be writing software in the first place. Tomorrow your manager may
>>>tell you that your N million line application has been sold - oh and I promised
>>you will deliver the port next month...
>>>
>>True _IFF_ one writes embedded code. Not if one designs applications intended only for x86.
>>People treating C/C++ as some kind of universal language will never get close to speed of light.
>
>There are multiple OSes and compilers in the x86 world. Then there is 32-bit vs
>64-bit. So you end up porting your software anyway even when you stay in the x86 world.
>
Eh you don't see the difference between architectural portability and OS portability?
Being portable between different operating systems is entirely a different matter. Algorithms and data structures are portable between x86 systems.

>And making your software portable does not at all mean losing performance. Understanding
>the issues will actually improve performance (eg. knowing that aligning data is good for performance on x86).
>
But that isn't true!
Look below at Richard Cownie's post. There are algorithms that can run faster on x86 because unaligned accesses are cheap! Within a cacheline they are very cheap, between cachelines they are reasonable, between aliased areas they are pretty expensive and between pages they can be expensive.
Well optimized x86 code often use unaligned accesses because that's the fastest way!

>>>>That is, as long as it runs fast and correct within well-defined platform constrains.
>>>>On x86 doing unaligned access is in most cases the best from performance perspective
>>>>so, as long as portability is not part of the spec, the software that in performance-critical
>>>>parts does something else could be considered badly written.
>>>
>>>Code with lots of misaligned accesses typically doesn't run fast - not even on
>>>x86 as there is always a penalty. There certainly are a few key examples where they
>>>improve performance, but apart from those, unaligned accesses don't help much, even there wasn't any penalty.
>>>
>>"lots of misaligned accesses" is something you wrote not the parent.
>>X86 have a penalty for unaligned accesses however there are many cases where not
>>specializing code to handle a handful of unaligned accesses is much faster. This
>>can be compared with architectures not supporting unaligned accesses at all where
>>the comparable code have to be slow to catch the few misaligned accesses there are.
>
>That's not how it works. If there are a few unaligned cases then one would ensure
>those few cases are either aligned or dealt with specially in some other way. So
>your performance critical code doesn't need to be slowed down in any way. However
>I accept it takes extra effort to track down and fix the unaligned cases, and that
>is why people prefer having hardware unaligned accesses.
>
How can one do that without specialization (=manual code replication + dynamic selection) for a dynamic data stream?

>>>However you can use unaligned accesses safely and portably. So in cases where it
>>>does improve performance or is required to process unaligned data it's perfectly
>>>fine. I consider it badly written if the unaligned access isn't explicitly marked
>>>- in those cases it is often not only a correctness bug but also a performance hog.
>>>
>>>Wilco
>>
>>There are many cases where it isn't possible to do it explicitly, the standard
>>languages aren't powerful enough for that.
>
>I can't imagine a case where it isn't powerful enough. You could describe the fact
>that an int pointer passed to a function may be unaligned by declaring it as void*.
>Then whenever you cast it to int* you know that you either need a runtime check
>or always do the access one byte at a time. With a few simple defines this can be both portable as well as optimal.
>
>Wilco
I'm not talking about a single access, I'm talking of real code handling dynamic alignment in a input stream, how do you describe that in C?

X86 != RISC processor with unaligned handling in a exception handler. Most unaligned cases are "free".