Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Windows 10 on ARM

channel9.msdn.com

Post reply on HN
Print view View original

271–280 of 290 posts

Re: Windows 10 on ARM

#271

Post by valarauca1 »

vardump wrote: post #222
wfunction wrote: post #178

Earlier quoted context omitted.

Admittedly more than I expected, and thanks for sharing, but "20 CPUs executing a peak of 224 instructions each" is a far cry from "modern processors execute THOUSANDS of instructions AHEAD". It's neither "thousands" of instructions in flight for a single processor, nor is it thousands "ahead" for multiple processors, let alone both. It's like taking 4000 basic single-stage CPUs and claiming they execute thousands of…

Agreed, saying thousands was hyperbole. You do have a point. When talking about instruction windows, one should talk only about one core at a time. Although the idea of "lots of instructions in flight" was right. From programmers' point of view there's no difference between out-of-order windows of tens, hundreds or thousands. One just needs to be prepared that CPU can and will reorder things within limits of the defi…

>one should talk only about one core at a time.

Nope.

Because we're talking about cross-core guarantees of concurrency. So you actually do care about what another, or all cores are doing.

What core is loading what, and what core is storing what.. and what is pending/holding up those loads is actually extremely important from the perspective of atomic guarantees.

Weaker CPU's (Like say POWER7) that do batching writes (you accumulate 256bits of data, then write it all at once) don't communicate what is in their write-out buffer. So you may write to a pointer, but until that CPU does a batched write the other cores aren't aware. You have to do a fence to flush this buffer (in the other cores).

There are some scenarios where the same situation can arise on x64 but its rarer. The intel cache architecture attempts to negotiate and detect when you are/aren't sharing data between cores. So for _most_ writes it uses the same situation as POWER7, but if it can predict your sharing data it'll use a different bus and alert the other CPU directly.

This is why x64 uses a MESIF-esque cache protocol [1][2]. It can tell when data is Owned/Forwarded/Shared between cores.

[1] https://en.wikipedia.org/wiki/MESIF_protocol

[2] Intel hasn't updated their white papers in 5+ years they're likely using a more advanced protocol.

Re: Windows 10 on ARM

#272

Post by PopsiclePete »

bborud wrote: post #86
Ezhik wrote: post #61

Earlier quoted context omitted.

They actually did namedrop Dave Cutler in the main keynote earlier, although in the context of talking about the Linux Subsystem.

That must kill him inside.

Maybe it's punishment for screwing up? I just picture him grinding his teeth and cursing under this breath the whole time....

Re: Windows 10 on ARM

#273

Post by ericfrederich »

If they're supporting x86 emulation to run desktop apps will they support compiling native desktop ARM apps?

They're essentially supporting the end result, I would hope they don't force developers to go through emulation to try to encourage them to write a universal windows app

Re: Windows 10 on ARM

#274

Post by vardump »

StillBored wrote: post #267
vardump wrote: post #220

Earlier quoted context omitted.

You're talking about atomic operations and synchronization. This is not about that. This is about memory order. How CPU is allowed to reorder normal unsynchronized loads and stores. X86 has strong order, but ARM CPUs can reorder loads and stores significantly more. Thus on ARM you very often need memory barriers on ARM where x86 needs none. If memory order is not handled according to specifications, programs executin…

Yes it is (about atomics/sync). ARM like every other major core is "sequentially consistent" with respect to the core executing the code. The memory order only matters for external visibility (aka other threads or devices). This means that the load/store order from a single thread doesn't matter to the other threads except at synchronization points (aka locks/etc). Those sync primitives have implied barriers. If some…

> If someone has a program which is depending on load/store order in userspace then they likely have bugs on x86 as well

Incorrect. On x86, if you write to memory n times, other cores are guaranteed to see the writes in same order. Second write is never going to be visible to other cores before first write. It's correct to rely on x86 memory model in x86 software.

On ARM, those stores can become visible to other cores in any order.

> since threads can be migrated between cores

Irrelevant. This is about code executing concurrently on multiple cores. Operating system and threads are irrelevant. This is about hardware behavior, CPU core load/store system and instruction reordering, not software.

> ... and the compilers are fully allowed to reorder load/stores...

This has nothing to do with compilers. This has everything to do how CPU cores reorder reads and writes.

> Particularly as GCC and friends get more aggressive about determining side effects and tossing code

If GCC has bugs, please report them. Undefined behavior can give that impression, but again, this topic has nothing to do with compilers.

> An emulator is also going to maintain this contract as well. That is why things like qemu work just fine to run x86 binaries on random ARMs today without having to modify the hardware memory model.

This is not true. See: http://wiki.qemu.org/Features/tcg-multithread#Memory_consist...

Remaining Case: strong on weak, ex. emulating x86 memory model on ARM systems

I recommend you read this: https://en.wikipedia.org/wiki/Memory_ordering.

Re: Windows 10 on ARM

#275

Post by 0x0 »

dis-sys wrote: post #187
0x0 wrote: post #183

Earlier quoted context omitted.

Not just the memory model, unaligned word/dword accesses would be tricky too I think? Doesn't ARM usually silently give you garbage when you load or store a multibyte item into a register unaligned?

In linux, you get a nice SIGBUS for unaligned memory access.

It looks like that's not the default, though? https://www.kernel.org/doc/Documentation/arm/mem_alignment

Re: Windows 10 on ARM

#276

Post by vardump »

valarauca1 wrote: post #271
vardump wrote: post #222

Earlier quoted context omitted.

Agreed, saying thousands was hyperbole. You do have a point. When talking about instruction windows, one should talk only about one core at a time. Although the idea of "lots of instructions in flight" was right. From programmers' point of view there's no difference between out-of-order windows of tens, hundreds or thousands. One just needs to be prepared that CPU can and will reorder things within limits of the defi…

>one should talk only about one core at a time. Nope. Because we're talking about cross-core guarantees of concurrency. So you actually do care about what another, or all cores are doing. What core is loading what, and what core is storing what.. and what is pending/holding up those loads is actually extremely important from the perspective of atomic guarantees. Weaker CPU's (Like say POWER7) that do batching writes…

> Because we're talking about cross-core guarantees of concurrency. So you actually do care about what another, or all cores are doing.

This is mostly about load/store order of an individual core. How individual core decides to order its reads and writes to memory.

> Weaker CPU's (Like say POWER7) that do batching writes (you accumulate 256bits of data, then write it all at once) don't communicate what is in their write-out buffer. So you may write to a pointer, but until that CPU does a batched write the other cores aren't aware. You have to do a fence to flush this buffer (in the other cores).

You can actually do same on x86 by using non-temporal stores. Although you're not talking about store ordering, but about visibility to other cores. A store won't ever be visible to other cores until it at least hits L1 cache controller.

> There are some scenarios where the same situation can arise on x64 but its rarer.

Yup, that's right. That's why x86 (and x64) got mfence and sfence instructions.

> This is why x64 uses a MESIF-esque cache protocol [1][2]. It can tell when data is Owned/Forwarded/Shared between cores.

Reordering happens before cache controller. When cache controller is involved, the store is already in progress.

Re: Windows 10 on ARM

#277

Post by StillBored »

vardump wrote: post #274
StillBored wrote: post #267

Earlier quoted context omitted.

Yes it is (about atomics/sync). ARM like every other major core is "sequentially consistent" with respect to the core executing the code. The memory order only matters for external visibility (aka other threads or devices). This means that the load/store order from a single thread doesn't matter to the other threads except at synchronization points (aka locks/etc). Those sync primitives have implied barriers. If some…

> If someone has a program which is depending on load/store order in userspace then they likely have bugs on x86 as well Incorrect. On x86, if you write to memory n times, other cores are guaranteed to see the writes in same order. Second write is never going to be visible to other cores before first write. It's correct to rely on x86 memory model in x86 software. On ARM, those stores can become visible to other core…

> It's correct to rely on x86 memory model in x86 software.

If you have complete control over the whole stack, sure. But we are taking windows user space applications. You continue to ignore my point originally that the edge cases you are describing may cause problems, but are just that, edge cases which can be solved with slow path code (put a DSB following every store if you like), and are likely depending on behaviors higher in the stack which aren't guaranteed and are therefor "broken". If your code is in assembly, and never makes library calls, etc then you might consider it "correctly written" otherwise your probably fooling yourself for the couple percent you gain over simply calling EnterCriticalSection().

Re: Windows 10 on ARM

#278

Post by StillBored »

vardump wrote: post #274
StillBored wrote: post #267

Earlier quoted context omitted.

Yes it is (about atomics/sync). ARM like every other major core is "sequentially consistent" with respect to the core executing the code. The memory order only matters for external visibility (aka other threads or devices). This means that the load/store order from a single thread doesn't matter to the other threads except at synchronization points (aka locks/etc). Those sync primitives have implied barriers. If some…

> If someone has a program which is depending on load/store order in userspace then they likely have bugs on x86 as well Incorrect. On x86, if you write to memory n times, other cores are guaranteed to see the writes in same order. Second write is never going to be visible to other cores before first write. It's correct to rely on x86 memory model in x86 software. On ARM, those stores can become visible to other core…

> On ARM, those stores can become visible to other cores in any order.

And I will repeat this again, for "correctly" written code this doesn't matter. Because the data areas being stored to should be protected by _LOCKs_ which will enforce visibility. If you think your being clever and writing "lock free" code by depending on the memory model your likely fooling yourself.

Re: Windows 10 on ARM

#279

Post by vardump »

StillBored wrote: post #278
vardump wrote: post #274

Earlier quoted context omitted.

> If someone has a program which is depending on load/store order in userspace then they likely have bugs on x86 as well Incorrect. On x86, if you write to memory n times, other cores are guaranteed to see the writes in same order. Second write is never going to be visible to other cores before first write. It's correct to rely on x86 memory model in x86 software. On ARM, those stores can become visible to other core…

> On ARM, those stores can become visible to other cores in any order. And I will repeat this again, for "correctly" written code this doesn't matter. Because the data areas being stored to should be protected by _LOCKs_ which will enforce visibility. If you think your being clever and writing "lock free" code by depending on the memory model your likely fooling yourself.

Lock free code indeed does indeed need to rely on memory model. Relying on underlying machine model is not fooling oneself.

Please don't conflate visibility with load/store order. It's a different matter.

See how C++ memory model operations map to different processors, especially how many cases are simple loads or stores on x86.

https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html (link from another comment in this discussion)

Re: Windows 10 on ARM

#280

Post by vardump »

StillBored wrote: post #277
vardump wrote: post #274

Earlier quoted context omitted.

> If someone has a program which is depending on load/store order in userspace then they likely have bugs on x86 as well Incorrect. On x86, if you write to memory n times, other cores are guaranteed to see the writes in same order. Second write is never going to be visible to other cores before first write. It's correct to rely on x86 memory model in x86 software. On ARM, those stores can become visible to other core…

> It's correct to rely on x86 memory model in x86 software. If you have complete control over the whole stack, sure. But we are taking windows user space applications. You continue to ignore my point originally that the edge cases you are describing may cause problems, but are just that, edge cases which can be solved with slow path code (put a DSB following every store if you like), and are likely depending on behav…

> If you have complete control over the whole stack, sure. But we are taking windows user space applications.

Well, hardware feature is a hardware feature. Load/store ordering is a hardware feature.

Operating system, user space or kernel space, compiler, etc. are not relevant when discussing about CPU core hardware operation.

You don't need complete control of the stack. You just need to have CPU cores executing instructions on multiple cores.

Post reply on HN