By: Michael S (already5chosen.delete@this.yahoo.com), July 13, 2020 11:02 am
Room: Moderated Discussions
Jörn Engel (joern.delete@this.purestorage.com) on July 13, 2020 10:10 am wrote:
> Jukka Larja (roskakori2006.delete@this.gmail.com) on July 13, 2020 8:38 am wrote:
> > Jörn Engel (joern.delete@this.purestorage.com) on July 12, 2020 11:35 am wrote:
> >
> > > Simple parsers.
> >
> > Don't take this the wrong way, but do you think a parser
> > is still simple, if you use SIMD to implement it? If
> > I wrote a parser like that at work, either of two things would happen: 1) I'd be the only one ever touching
> > the code, or 2) someone else would need to touch the code, and would promptly reimplement it without SIMD.
>
> Any code you vectorize ends up less pleasant to read or work with. Not sure
> if simple is the right term, but just like assembler, you end up with a small
> subset of programmers still willing to look at the code and work with it.
>
> I have vectorized simple parsers. If they had been much more complicated it
> would have overflowed both my brain capacity and the available registers.
>
> > > Data modifications like matrix transpose or similar. Dot-products.
> >
> > We do some vector and matrix algebra with SIMD, but I can't say much about
> > it. It's mostly based on vector4, so only makes use of four wide SIMD.
>
> That sounds like you have 32bit or 64bit types. I agree, going 4x faster
> isn't that exciting. If you can get by with smaller data types and go 16x
> or 32x faster, you are willing to suffer a bit more for that advantage.
>
> > > I think of vector programming similar to object orientation
> > > or functional programming. If you read an article
> > > and play around with it for a day you probably won't get it or see any benefit. But if you commit some
> > > time and allow your brain to rewire you start to see more and more applications where it helps.
> >
> > I'm sure if I spent significant time with SIMD, I'd see
> > more places where it could make sense. However, I've
> > already spent more time with it than most programmers ever
> > will. If I can't name a single place in our million
> > line codebase to make real use of it, how could I expect it will have significance in the future?
>
> Run a profiler and see what stands out. If you have one thing responsible for 10% of runtime, it might be worth
> it. Or if you have one thing you don't do because it costs too much. And just like OO or functional programming,
> you don't have to do it just because the cool kids seem to. Only do it if it makes sense to you.
>
> > > And the biggest impediment is that we don't have a nice way to express vector code.
> > > Assembler is, well, assembler. Intel intrinsics are assembler disguised as C functions
> > > with a syntax that seems universally detested. I ended up writing my own small library
> > > simply to be able to read my own code two months later without going crazy.
> >
> > The problem for me is that pretty much only abstraction that I know could be easily used
> > would be Vec3 operations, and that at the best gives just 3x improvement[1]. Even the amount
> > of matrix calculations in a game engine are low. All the hard work happens on GPU.
>
> The abstraction I wanted and eventually noticed I could get is pretty much C syntax.
>
> a += b;
> a >>= 4;
>
> That is code I can read and work with. It doesn't make a huge difference whether "a" is a
> u8, u64 or vector of u16. It took me about a year of suffering until I realized that it's
> possible to do that, you basically have to define your own types and then provide wrapper functions
> every time you want to use Intel intrinsics to do the type casting back and forth.
>
> typedef uint16_t u16_256 __attribute__((vector_size(32), may_alias));
> typedef uint8_t u8_256u __attribute__((vector_size(32), may_alias, aligned(1)));
> static inline u8_256 read256(const void *buf) { return *(const u8_256u *)buf; }
> ...
>
> Now I have all intrinsics confined inside a header-library. If I come across some old code
> using intrinsics, I convert it before I even start reading. To me it dramatically reduces
> the brain-tax I have to pay for vectorization. As a result I started using it more.
>
If I stat to work on your code base the first thing I'd likely do would be removing all wrapper and using bare intrinsics. To me it dramatically reduces the brain-tax.
To each his own.
> I think C syntax is a wonderful thing and Ken Thomson was absolutely right when he decided
> that BCPL was mostly a fine language, except for the syntax. It is absolutely important
> to express simple things in simple terms without a ton of noise distracting you.
>
> a = _mm256_add_epi16(a, b);
> a = _mm256_srl_epi32(b, 4);
>
> Be honest, did you spot the two bugs I slipped into this code? If you didn't you were probably distracted
> by the noise. Having a single type for integer vectors of any size is another mistake. Typically
> if you start with u16, you want to continue with u16. That's why you select an appropriate type instead
> of specifying it with every single instruction. There are exceptions and you want the exceptions
> to stand out. If I see a cast I know that I need to pay attention. I also know that the programmer
> meant to do a cast instead of just typing epi32 when it should have been epi16.
> Jukka Larja (roskakori2006.delete@this.gmail.com) on July 13, 2020 8:38 am wrote:
> > Jörn Engel (joern.delete@this.purestorage.com) on July 12, 2020 11:35 am wrote:
> >
> > > Simple parsers.
> >
> > Don't take this the wrong way, but do you think a parser
> > is still simple, if you use SIMD to implement it? If
> > I wrote a parser like that at work, either of two things would happen: 1) I'd be the only one ever touching
> > the code, or 2) someone else would need to touch the code, and would promptly reimplement it without SIMD.
>
> Any code you vectorize ends up less pleasant to read or work with. Not sure
> if simple is the right term, but just like assembler, you end up with a small
> subset of programmers still willing to look at the code and work with it.
>
> I have vectorized simple parsers. If they had been much more complicated it
> would have overflowed both my brain capacity and the available registers.
>
> > > Data modifications like matrix transpose or similar. Dot-products.
> >
> > We do some vector and matrix algebra with SIMD, but I can't say much about
> > it. It's mostly based on vector4, so only makes use of four wide SIMD.
>
> That sounds like you have 32bit or 64bit types. I agree, going 4x faster
> isn't that exciting. If you can get by with smaller data types and go 16x
> or 32x faster, you are willing to suffer a bit more for that advantage.
>
> > > I think of vector programming similar to object orientation
> > > or functional programming. If you read an article
> > > and play around with it for a day you probably won't get it or see any benefit. But if you commit some
> > > time and allow your brain to rewire you start to see more and more applications where it helps.
> >
> > I'm sure if I spent significant time with SIMD, I'd see
> > more places where it could make sense. However, I've
> > already spent more time with it than most programmers ever
> > will. If I can't name a single place in our million
> > line codebase to make real use of it, how could I expect it will have significance in the future?
>
> Run a profiler and see what stands out. If you have one thing responsible for 10% of runtime, it might be worth
> it. Or if you have one thing you don't do because it costs too much. And just like OO or functional programming,
> you don't have to do it just because the cool kids seem to. Only do it if it makes sense to you.
>
> > > And the biggest impediment is that we don't have a nice way to express vector code.
> > > Assembler is, well, assembler. Intel intrinsics are assembler disguised as C functions
> > > with a syntax that seems universally detested. I ended up writing my own small library
> > > simply to be able to read my own code two months later without going crazy.
> >
> > The problem for me is that pretty much only abstraction that I know could be easily used
> > would be Vec3 operations, and that at the best gives just 3x improvement[1]. Even the amount
> > of matrix calculations in a game engine are low. All the hard work happens on GPU.
>
> The abstraction I wanted and eventually noticed I could get is pretty much C syntax.
>
> a += b;
> a >>= 4;
>
> That is code I can read and work with. It doesn't make a huge difference whether "a" is a
> u8, u64 or vector of u16. It took me about a year of suffering until I realized that it's
> possible to do that, you basically have to define your own types and then provide wrapper functions
> every time you want to use Intel intrinsics to do the type casting back and forth.
>
> typedef uint16_t u16_256 __attribute__((vector_size(32), may_alias));
> typedef uint8_t u8_256u __attribute__((vector_size(32), may_alias, aligned(1)));
> static inline u8_256 read256(const void *buf) { return *(const u8_256u *)buf; }
> ...
>
> Now I have all intrinsics confined inside a header-library. If I come across some old code
> using intrinsics, I convert it before I even start reading. To me it dramatically reduces
> the brain-tax I have to pay for vectorization. As a result I started using it more.
>
If I stat to work on your code base the first thing I'd likely do would be removing all wrapper and using bare intrinsics. To me it dramatically reduces the brain-tax.
To each his own.
> I think C syntax is a wonderful thing and Ken Thomson was absolutely right when he decided
> that BCPL was mostly a fine language, except for the syntax. It is absolutely important
> to express simple things in simple terms without a ton of noise distracting you.
>
> a = _mm256_add_epi16(a, b);
> a = _mm256_srl_epi32(b, 4);
>
> Be honest, did you spot the two bugs I slipped into this code? If you didn't you were probably distracted
> by the noise. Having a single type for integer vectors of any size is another mistake. Typically
> if you start with u16, you want to continue with u16. That's why you select an appropriate type instead
> of specifying it with every single instruction. There are exceptions and you want the exceptions
> to stand out. If I see a cast I know that I need to pay attention. I also know that the programmer
> meant to do a cast instead of just typing epi32 when it should have been epi16.
Topic | Posted By | Date |
---|---|---|
Alder Lake and AVX-512 | me | 2020/07/11 07:02 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/11 11:41 AM |
informative (NT) | blue | 2020/07/11 12:40 PM |
grumpy | Michael S | 2020/07/11 12:51 PM |
grumpy | me | 2020/07/11 01:27 PM |
area and power cost of AVX-512 | Michael S | 2020/07/11 12:58 PM |
area and power cost of AVX-512 | Anon | 2020/07/11 04:35 PM |
area and power cost of AVX-512 | Michael S | 2020/07/12 04:16 AM |
area and power cost of AVX-512 | Travis Downs | 2020/07/12 09:13 AM |
area and power cost of AVX-512 | Travis Downs | 2020/07/11 07:19 PM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/11 02:02 PM |
Alder Lake and AVX-512 | Ungo | 2020/07/11 05:28 PM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/11 10:16 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/11 06:51 PM |
Alder Lake and AVX-512 | ⚛ | 2020/07/12 01:48 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 03:07 PM |
HDR | Anon3 | 2020/07/12 03:42 PM |
HDR10 in Kaby Lake? | David Kanter | 2020/07/12 05:09 PM |
HDR10 in Kaby Lake? | Maynard Handley | 2020/07/12 06:13 PM |
Thanks for the link (NT) | David Kanter | 2020/07/12 06:43 PM |
HDR10 in Kaby Lake? | Anon3 | 2020/07/13 01:36 AM |
Alder Lake and AVX-512 | Dummond D. Slow | 2020/07/12 03:00 PM |
AVX-512 with narrow ex units? | m | 2020/07/23 12:10 PM |
AVX-512 with narrow ex units? | Anon | 2020/07/23 12:53 PM |
AVX-512 with narrow ex units? | Paul A. Clayton | 2020/07/23 06:32 PM |
AVX-512 with narrow ex units? | Anon | 2020/07/23 06:50 PM |
AVX-512 with narrow ex units? | Paul A. Clayton | 2020/07/23 07:45 PM |
AVX-512 with narrow ex units? | Anon | 2020/07/23 08:15 PM |
AVX-512 with narrow ex units? | Jukka Larja | 2020/07/24 04:44 AM |
AVX-512 with narrow ex units? | Gabriele Svelto | 2020/07/24 02:56 PM |
AVX-512 with narrow ex units? | Jouni Osmala | 2020/07/24 09:22 PM |
AVX-512 with narrow ex units? | Jukka Larja | 2020/07/25 01:32 AM |
AVX-512 with narrow ex units? | Eugene Nalimov | 2020/07/25 05:56 PM |
AVX-512 with narrow ex units? | Jukka Larja | 2020/07/26 01:28 AM |
AVX-512 with narrow ex units? | Gabriele Svelto | 2020/07/26 02:22 PM |
AVX-512 with narrow ex units? | Jukka Larja | 2020/07/27 07:00 AM |
AVX-512 with narrow ex units? | -.- | 2020/07/23 06:32 PM |
AVX-512 with narrow ex units? | Travis Downs | 2020/07/24 05:01 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/11 04:45 PM |
Alder Lake and AVX-512 | Chester | 2020/07/11 05:26 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/11 06:22 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 02:02 AM |
Alder Lake and AVX-512 | Travis Downs | 2020/07/13 09:01 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/11 06:54 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/11 08:01 PM |
Alder Lake and AVX-512 | N Owen | 2020/07/12 12:37 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 01:48 AM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 07:13 PM |
Alder Lake and AVX-512 | Travis Downs | 2020/07/13 09:09 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/13 11:42 PM |
Alder Lake and AVX-512 | Doug S | 2020/07/11 11:49 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 01:53 AM |
Alder Lake and AVX-512 | Travis Downs | 2020/07/11 07:03 PM |
Alder Lake and AVX-512 | Veedrac | 2020/07/11 07:43 PM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 01:31 AM |
Alder Lake and AVX-512 | Veedrac | 2020/07/12 04:01 AM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 03:26 PM |
Alder Lake and AVX-512 | Anon3 | 2020/07/12 04:07 PM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 05:39 PM |
Alder Lake and AVX-512 | Veedrac | 2020/07/12 04:21 PM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 05:33 PM |
Alder Lake and AVX-512 | Veedrac | 2020/07/12 05:54 PM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 06:20 PM |
Alder Lake and AVX-512 | David Hess | 2020/07/12 07:32 PM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 08:41 PM |
Alder Lake and AVX-512 | ⚛ | 2020/07/13 04:02 AM |
Alder Lake and AVX-512 | anon2 | 2020/07/13 07:25 PM |
PentiumMMX vs Transmeta's VLIW in hindsight | ⚛ | 2020/07/19 06:16 AM |
PentiumMMX vs Transmeta's VLIW in hindsight | Maynard Handley | 2020/07/19 10:47 AM |
PentiumMMX vs Transmeta's VLIW in hindsight | anon2 | 2020/07/19 03:24 PM |
VLIW, OOO, Pairing, and Fusion | Chester | 2020/07/19 10:16 PM |
Poulson was in-order (NT) | anon2 | 2020/07/20 12:20 AM |
VLIW, OOO, Pairing, and Fusion | Michael S | 2020/07/20 12:48 AM |
Itanium is NOT VLIW | Heikki Kultala | 2020/07/20 02:27 PM |
Itanium is NOT VLIW | Adrian | 2020/07/20 11:03 PM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | Heikki Kultala | 2020/07/21 03:38 AM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | anon2 | 2020/07/21 05:03 AM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | dmcq | 2020/07/21 03:27 PM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | j | 2020/07/21 08:54 AM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | Tim McCaffrey | 2020/07/21 10:30 AM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | Linus Torvalds | 2020/07/21 09:13 AM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Heikki Kultala | 2020/07/22 12:31 PM |
Turn that on its head? | Ray | 2020/07/22 12:49 PM |
Turn that on its head? | Anon | 2020/07/22 01:53 PM |
Turn that on its head? | Maynard Handley | 2020/07/22 02:37 PM |
Turn that on its head? | anon2 | 2020/07/22 03:32 PM |
Turn that on its head? | anon3 | 2020/07/22 04:45 PM |
Turn that on its head? | Heikki Kultala | 2020/07/23 02:53 AM |
Turn that on its head? | Anon | 2020/07/23 10:20 AM |
Turn that on its head? | Heikki Kultala | 2020/07/23 11:21 AM |
Turn that on its head? | Brett | 2020/07/23 03:26 PM |
Turn that on its head? | Brett | 2020/07/24 04:22 AM |
Bundling OOO entries does this implicitly | David Kanter | 2020/07/23 10:56 AM |
Turn that on its head? | anon | 2020/07/23 11:49 AM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Maynard Handley | 2020/07/22 02:29 PM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | wumpus | 2020/07/22 03:16 PM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Doug S | 2020/07/22 10:37 PM |
what Intel would have done | Michael S | 2020/07/23 12:46 AM |
what Intel would have done | Doug S | 2020/07/23 09:52 AM |
what Intel would have done | Anon | 2020/07/23 10:25 AM |
what Intel would have done | Michael S | 2020/07/23 11:23 AM |
what Intel would have done | Montaray Jack | 2020/07/23 06:08 PM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Heikki Kultala | 2020/07/22 11:47 PM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | wumpus | 2020/07/23 01:46 PM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Michael S | 2020/07/23 12:56 AM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Heikki Kultala | 2020/07/23 02:44 AM |
thanks | Chester | 2020/07/24 03:50 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/11 07:46 PM |
Alder Lake and AVX-512 | never_released | 2020/07/11 08:54 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 02:25 AM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 01:36 AM |
Alder Lake and AVX-512 | Doug S | 2020/07/12 12:01 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 02:41 AM |
Alder Lake and AVX-512 | rwessel | 2020/07/12 10:17 AM |
Alder Lake and AVX-512 | -.- | 2020/08/18 03:24 AM |
Alder Lake and AVX-512 | Travis Downs | 2020/08/18 11:04 PM |
Alder Lake and AVX-512 | Geoff Langdale | 2020/07/11 07:49 PM |
Alder Lake and AVX-512 | anon | 2020/07/11 08:12 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/11 08:33 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 03:00 AM |
Alder Lake and AVX-512 | Jukka Larja | 2020/07/12 08:51 AM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/12 10:30 AM |
Alder Lake and AVX-512 | Jukka Larja | 2020/07/13 07:43 AM |
Alder Lake and AVX-512 | Montaray Jack | 2020/07/23 07:20 PM |
Alder Lake and AVX-512 | Jukka Larja | 2020/07/24 04:57 AM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/12 11:35 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 12:01 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 12:15 PM |
Alder Lake and AVX-512 | anonymou5 | 2020/07/12 01:50 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 02:31 PM |
Alder Lake and AVX-512 | anonymou5 | 2020/07/12 03:09 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 04:25 PM |
Alder Lake and AVX-512 | anonymou5 | 2020/07/12 08:34 PM |
Alder Lake and AVX-512 | Jose | 2020/07/13 01:35 AM |
Alder Lake and AVX-512 | gallier2 | 2020/07/13 02:11 AM |
Alder Lake and AVX-512 | gallier2 | 2020/07/13 02:01 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/13 11:06 AM |
Alder Lake and AVX-512 | Doug S | 2020/07/13 12:11 PM |
Alder Lake and AVX-512 | Brett | 2020/07/14 02:34 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/14 09:02 AM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/14 12:40 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/14 12:48 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/15 01:37 AM |
OS X file names normalization | Michael S | 2020/07/15 02:26 AM |
OS X file names normalization | Simon Farnsworth | 2020/07/15 04:16 AM |
OS X file names normalization | Michael S | 2020/07/15 10:51 AM |
OS X file names normalization | Simon Farnsworth | 2020/07/15 12:27 PM |
OS X file names normalization | Doug S | 2020/07/15 10:46 AM |
OS X file names normalization | Michael S | 2020/07/15 11:05 AM |
OS X file names normalization | Linus Torvalds | 2020/07/15 12:58 PM |
OS X file names normalization | Linus Torvalds | 2020/07/15 02:21 PM |
OS X file names normalization | gallier2 | 2020/07/15 11:57 PM |
OS X file names normalization | gallier2 | 2020/07/15 11:44 PM |
OS X file names normalization | Rob Thorpe | 2020/07/15 11:23 AM |
OS X file names normalization | Doug S | 2020/07/15 01:32 PM |
OS X file names normalization | Maynard Handley | 2020/07/15 05:20 PM |
OS X file names normalization | Linus Torvalds | 2020/07/15 08:37 PM |
OS X file names normalization | Anon3 | 2020/07/16 01:43 PM |
OS X file names normalization | Doug S | 2020/07/16 03:38 PM |
OS X file names normalization | Linus Torvalds | 2020/07/17 12:21 AM |
OS X file names normalization | Anon3 | 2020/07/17 02:15 AM |
OS X file names normalization | Jukka Larja | 2020/07/17 06:40 AM |
OS X file names normalization | gallier2 | 2020/07/17 03:19 AM |
OS X file names normalization | Linus Torvalds | 2020/07/17 09:41 AM |
OS X file names normalization | Dummond D. Slow | 2020/07/17 09:54 AM |
OS X file names normalization | Linus Torvalds | 2020/07/17 10:16 AM |
OS X file names normalization | Simon Farnsworth | 2020/07/18 06:12 AM |
OS X file names normalization | Anon3 | 2020/07/17 02:04 AM |
OS X file names normalization | Doug S | 2020/07/17 10:15 AM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/15 10:32 AM |
File Systems and VC Problems | Rob Thorpe | 2020/07/15 07:24 AM |
vectorization of utf8 | Robert David Graham | 2020/07/13 02:36 PM |
vectorization of utf8 | anon2 | 2020/07/13 05:07 PM |
vectorization of utf8 | Robert David Graham | 2020/07/13 08:36 PM |
vectorization of utf8 | anon2 | 2020/07/13 11:23 PM |
vectorization of utf8 | Maynard Handley | 2020/07/13 10:46 PM |
vectorization of utf8 | Gabriele Svelto | 2020/07/15 03:27 AM |
Alder Lake and AVX-512 | gallier2 | 2020/07/14 01:13 AM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/12 01:29 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 02:08 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/12 06:26 PM |
Alder Lake and AVX-512 | -.- | 2020/07/12 07:11 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/12 07:43 PM |
Alder Lake and AVX-512 | Jukka Larja | 2020/07/13 08:38 AM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/13 10:10 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/13 11:02 AM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/13 11:22 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/13 12:10 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/13 04:03 PM |
Alder Lake and AVX-512 | Jukka Larja | 2020/07/14 06:53 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/11 08:34 PM |
Alder Lake and AVX-512 | Brett | 2020/07/11 09:02 PM |
Alder Lake and AVX-512 | David Hess | 2020/07/13 12:36 PM |
Alder Lake and AVX-512 | anonymou5 | 2020/07/13 01:01 PM |
Alder Lake and AVX-512 | Brett | 2020/07/13 04:19 PM |
Alder Lake and AVX-512 | Geert | 2020/07/11 09:36 PM |
AMD's FPU | Chester | 2020/07/12 02:28 AM |
Is 3|5 lower than 4? | Michael S | 2020/07/12 03:59 AM |
Is 3|5 lower than 4? | Chester | 2020/07/12 05:54 AM |
Alder Lake and AVX-512 | Geoff Langdale | 2020/07/11 11:45 PM |
Alder Lake and AVX-512 | me | 2020/07/12 03:44 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 04:09 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 11:35 AM |
~80% of details are wrong. So what one can expect from conclusions? :( (NT) | Michael S | 2020/07/12 11:57 AM |
~80% of details are wrong. So what one can expect from conclusions? :( | anonymous2 | 2020/07/12 12:50 PM |
Alder Lake and AVX-512 | nobody in particular | 2020/07/12 12:25 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 12:37 PM |
Alder Lake and AVX-512 | nobody in particular | 2020/07/12 12:43 PM |
Alder Lake and AVX-512 | me | 2020/07/12 01:32 PM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/12 08:51 PM |
Alder Lake and AVX-512 | UnmaskedUnderflow | 2020/07/12 12:33 PM |
AVX-512 vs SVE2 | -.- | 2020/07/12 06:22 PM |
AVX-512 vs SVE2 | noko | 2020/07/13 12:12 AM |
AVX-512 vs SVE2 | -.- | 2020/07/13 04:00 AM |
Alder Lake and AVX-512 | Geoff Langdale | 2020/07/12 08:18 PM |
Could you please stop top-posting (NT) | Jukka Larja | 2020/07/13 08:45 AM |
Alder Lake and AVX-512 | Romain Dolbeau | 2020/07/15 01:00 AM |
Alder Lake and AVX-512 | Spiteful Sprites | 2020/07/13 04:59 AM |
Alder Lake and AVX-512 | nobody in particular | 2020/07/13 09:12 AM |
Alder Lake and AVX-512 | Spiteful Sprites | 2020/07/13 04:21 PM |
Alder Lake and AVX-512 | Jouni Osmala | 2020/07/14 02:55 AM |
RISC-V & commercial support (was: Alder Lake and AVX-512) | Romain Dolbeau | 2020/07/15 01:11 AM |
RISC-V & commercial support (was: Alder Lake and AVX-512) | Romain Dolbeau | 2020/07/15 01:13 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/13 11:10 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Romain Dolbeau | 2020/07/14 10:09 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | anon | 2020/07/14 10:53 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Romain Dolbeau | 2020/07/14 11:27 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Maynard Handley | 2020/07/14 12:52 PM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Doug S | 2020/07/14 01:43 PM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | anon | 2020/07/14 03:01 PM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Linus Torvalds | 2020/07/14 12:00 PM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Romain Dolbeau | 2020/07/14 11:42 PM |
Configurable cache line size? | Doug S | 2020/07/15 10:56 AM |
Configurable cache line size? | dmcq | 2020/07/15 03:43 PM |
Configurable cache line size? | Romain Dolbeau | 2020/07/15 11:37 PM |
Configurable cache line size? | NoSpammer | 2020/07/16 01:27 AM |
Configurable cache line size? | Pixie | 2020/07/16 10:55 AM |
Configurable cache line size? | Etienne | 2020/07/17 01:03 AM |
Configurable cache line size? | Hugo Décharnes | 2020/07/18 02:11 AM |
Cache line size | Mark Roulo | 2020/07/15 06:10 PM |
Cache line size | anon | 2020/07/15 06:46 PM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Gabriele Svelto | 2020/07/17 02:30 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | dmcq | 2020/07/17 03:34 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | zArchJon | 2020/07/17 01:16 PM |
Macro-instructions to the rescue | ⚛ | 2020/07/24 12:56 PM |
Some fundamentals haven't changed | Chester | 2020/07/24 03:59 PM |
Some fundamentals haven't changed | ⚛ | 2020/07/24 04:24 PM |
Some fundamentals haven't changed | dmcq | 2020/07/25 07:58 AM |
Some fundamentals haven't changed | ⚛ | 2020/07/25 11:05 AM |
Some fundamentals haven't changed | Brett | 2020/07/25 02:16 PM |
Some fundamentals haven't changed | Brett | 2020/07/25 02:27 PM |
What belt is. | Heikki Kultala | 2020/07/26 07:49 AM |
What belt is. | Michael S | 2020/07/26 10:00 AM |
What belt is. | Brett | 2020/07/26 11:46 PM |
What belt is. | Michael S | 2020/07/27 12:52 AM |
What belt is. | Brett | 2020/07/27 07:25 AM |
What belt is. | Doug S | 2020/07/27 01:31 PM |
What belt is. | Andrew Clough | 2020/07/28 06:11 AM |
What belt is. | dmcq | 2020/07/28 08:17 AM |
Mill Compiler still MIA? | Geoff Langdale | 2020/07/28 05:04 PM |
If they release the compiler, how they will blame the still-in-development compiler for the lacklust (NT) | Anon | 2020/07/28 05:20 PM |
If they release the compiler, how they will blame the still-in-development compiler for the lacklust | Anon | 2020/07/28 05:20 PM |
Apparently they're busy writing a kernel... | Anon | 2020/07/29 03:03 AM |
Apparently they're busy writing a kernel... | dmcq | 2020/07/29 03:39 AM |
What belt is. | ⚛ | 2020/07/26 11:44 AM |
What belt is. | anonymous2 | 2020/07/26 12:02 PM |
What belt is. | Doug S | 2020/07/26 03:26 PM |
What belt is. | ⚛ | 2020/07/26 04:02 PM |
good | useruser | 2020/07/12 10:06 AM |
Alder Lake and AVX-512 | -.- | 2020/07/11 09:03 PM |
Alder Lake and AVX-512 | -.- | 2020/07/11 09:07 PM |
Alder Lake and AVX-512 | j | 2020/07/13 12:29 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/13 01:12 AM |
Alder Lake and AVX-512 | j | 2020/07/13 02:58 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/13 04:53 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/14 12:57 AM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/14 10:26 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/14 12:33 PM |
Alder Lake and AVX-512 | dmcq | 2020/07/14 03:43 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/15 12:55 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/15 02:19 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/15 02:34 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/15 03:03 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/15 09:43 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/15 09:54 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/15 11:35 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/15 03:18 PM |
GV100 + POWER9 | Michael S | 2020/07/16 01:17 AM |
GV100 + POWER9 | dmcq | 2020/07/16 08:58 AM |
GV100 + POWER9 | dmcq | 2020/07/16 09:10 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/15 02:48 AM |
Alder Lake and AVX-512 | o | 2020/07/12 03:08 AM |
Alder Lake and AVX-512 | ⚛ | 2020/07/12 11:07 AM |
Alder Lake and AVX-512 | ⚛ | 2020/07/12 11:32 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 11:39 AM |
Alder Lake and AVX-512 | ⚛ | 2020/07/12 12:47 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 01:18 PM |
x87 crap | Heikki Kultala | 2020/07/12 01:30 PM |
x87 crap | Michael S | 2020/07/12 01:37 PM |
x87 crap | Heikki kultala | 2020/07/12 02:11 PM |
x87 crap | Michael S | 2020/07/12 02:50 PM |
Sparc and PA-RISC vs pentium FP performance | Heikki Kultala | 2020/07/13 01:14 AM |
Sparc and PA-RISC vs pentium FP performance | anonymous2 | 2020/07/13 10:48 AM |
Alder Lake and AVX-512 | Doug S | 2020/07/12 03:33 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 04:10 PM |
Alder Lake and AVX-512 | David Kanter | 2020/07/12 05:01 PM |
Alder Lake and AVX-512 | anon | 2020/07/12 05:40 PM |
~0% of users do much FP outside of GPUs for games (NT) | anonymous2 | 2020/07/12 05:47 PM |
~0% of users do much FP outside of GPUs for games | Maynard Handley | 2020/07/13 12:26 AM |
not true | Chester | 2020/07/13 12:37 AM |
not true | Michael S | 2020/07/13 01:29 AM |
not true | Chester | 2020/07/13 01:59 AM |
not true | anonymous2 | 2020/07/13 10:32 AM |
not true | Maynard Handley | 2020/07/13 02:30 PM |
not true | Chester | 2020/07/14 05:47 AM |
not true | Doug S | 2020/07/13 12:30 PM |
not true | Anon | 2020/07/13 01:16 PM |
not true | Maynard Handley | 2020/07/13 02:39 PM |
not true | Maynard Handley | 2020/07/13 02:38 PM |
not true | Linus Torvalds | 2020/07/13 11:27 AM |
not true | Dummond D. Slow | 2020/07/13 02:10 PM |
not true | Maynard Handley | 2020/07/13 02:49 PM |
not true | Dummond D. Slow | 2020/07/13 03:38 PM |
not true (about FP, not avx-512) | Chester | 2020/07/17 10:37 AM |
Alder Lake and AVX-512 | Travis Downs | 2020/07/11 06:45 PM |
Alder Lake and AVX-512 | -.- | 2020/07/11 06:57 PM |
Alder Lake and AVX-512 | -.- | 2020/07/12 04:26 PM |