By: Michael S (already5chosen.delete@this.yahoo.com), July 11, 2013 2:43 pm
Room: Moderated Discussions
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 11, 2013 11:52 am wrote:
>
>
> There's a big difference between SSE and AVX. One is some rather basic vector
> and FP stuff, the other is pretty esoteric and has much less use.
>
Technically, there is nothing esoteric about AVX. It serves exactly the same purpose as SSE, but serves it better. Arguably, AVX, with possible exception of 256-bitness, is what SSE should have been from the day one, if back then Intel architects were smarter.
Scalar/128b AVX enhancements over SSE (more compact and regular encoding and non-destructive operations) even more advantageous for narrow mostly-in-order core like Silvermont than they are for fatter cores, because on such core both # of instructions per task and # of code bytes per task are scarcer.
Now, what is "esoteric" about AVX is ubiquity. Strangely, despite AVX being Intel's baby, Intel is also a main offender here.
> And yes, I'd also claim that any cellphone benchmark that uses
> AVX would be just crazy. Even crazier than using NEON.
>
That's a typical self-fulfilling prophecy. Of course, cellphone benchmark that uses
AVX would remain crazy as long as the only x86 manufacturer capable of making phone-class application processors does not implement AVX in its processors.
> So I absolutely stand by my point: I think it's absolutely insane to expect/want Atom
> to have AVX, when it's not even clear that all new Atoms will be 64-bit enabled. AVX is
> a niche thing that doesn't even make sense in a mobile or microserver environment.
>
So, ours ways of reasoning and our ideas of consistency just differ too much.
> And that is NOT AT ALL inconsistent with me then complaining that ARM doesn't make even
> basic floating point or the most basic vector support something you can really rely on.
>
> Happily, for the kernel, I don't need to care all that deeply. We avoid the use of FP for
> other general reasons, and so we don't see that. But the ARM situation annoys me because this
> whole "incompatible microarchitectures" goes so much deeper than just FP/vector: it's all
> over (Thumb2 or not? yadda yadda), and the whole architecture specification is a mess.
>
If I was you, I'd simply refuse to support new version of full-blown Linux on anything less than v7-A. Those who want to run on older or lesser variants would have to maintain their own forks or to use older versions of the kernel.
But, then again, if I was you, I'd likely have different considerations. As chess commentators used to say, it's easy to sacrifice other player's pieces.
>
>
> There's a big difference between SSE and AVX. One is some rather basic vector
> and FP stuff, the other is pretty esoteric and has much less use.
>
Technically, there is nothing esoteric about AVX. It serves exactly the same purpose as SSE, but serves it better. Arguably, AVX, with possible exception of 256-bitness, is what SSE should have been from the day one, if back then Intel architects were smarter.
Scalar/128b AVX enhancements over SSE (more compact and regular encoding and non-destructive operations) even more advantageous for narrow mostly-in-order core like Silvermont than they are for fatter cores, because on such core both # of instructions per task and # of code bytes per task are scarcer.
Now, what is "esoteric" about AVX is ubiquity. Strangely, despite AVX being Intel's baby, Intel is also a main offender here.
> And yes, I'd also claim that any cellphone benchmark that uses
> AVX would be just crazy. Even crazier than using NEON.
>
That's a typical self-fulfilling prophecy. Of course, cellphone benchmark that uses
AVX would remain crazy as long as the only x86 manufacturer capable of making phone-class application processors does not implement AVX in its processors.
> So I absolutely stand by my point: I think it's absolutely insane to expect/want Atom
> to have AVX, when it's not even clear that all new Atoms will be 64-bit enabled. AVX is
> a niche thing that doesn't even make sense in a mobile or microserver environment.
>
So, ours ways of reasoning and our ideas of consistency just differ too much.
> And that is NOT AT ALL inconsistent with me then complaining that ARM doesn't make even
> basic floating point or the most basic vector support something you can really rely on.
>
> Happily, for the kernel, I don't need to care all that deeply. We avoid the use of FP for
> other general reasons, and so we don't see that. But the ARM situation annoys me because this
> whole "incompatible microarchitectures" goes so much deeper than just FP/vector: it's all
> over (Thumb2 or not? yadda yadda), and the whole architecture specification is a mess.
>
If I was you, I'd simply refuse to support new version of full-blown Linux on anything less than v7-A. Those who want to run on older or lesser variants would have to maintain their own forks or to use older versions of the kernel.
But, then again, if I was you, I'd likely have different considerations. As chess commentators used to say, it's easy to sacrifice other player's pieces.
