By: Maynard Handley (name99.delete@this.name99.org), July 19, 2020 10:47 am
Room: Moderated Discussions
⚛ (0xe2.0x9a.0x9b.delete@this.gmail.com) on July 19, 2020 6:16 am wrote:
> anon2 (anon.delete@this.anon.com) on July 13, 2020 7:25 pm wrote:
> > ⚛ (0xe2.0x9a.0x9b.delete@this.gmail.com) on July 13, 2020 4:02 am wrote:
> > > Veedrac (ignore.delete@this.this.com) on July 12, 2020 4:21 pm wrote:
> > > > Intel's stagnation has made many people think of this as where we're at: single threaded
> > > > performance is stagnant because scaling isn't practical any more. I'm now certain this isn't remotely true.
> > >
> > > Maybe improvements in single-threaded IPC better fit a curve of punctuated equilibria
> > > rather than fitting the curve of steady gradual improvements over time.
> > >
> > > AMD, Intel and many others haven't tried to go the path of
> > > reducing the amount of redundant/repetitious dynamic
> > > computations in the CPU's out-of-order engine.
> >
> > How do you know?
>
> Is there some indication that AMD/Intel are reducing the amount of redundant/repetitious dynamic computations
> in Zen/SunnyCove's by storing that kind of information in the µop cache for example, such as:
>
> loop:
> ...
> mov -16(%rbp), %eax
> ...
> jne loop
>
> where "mov -16(%rbp), %eax" is replaced by "mov -16(%rbp_translated), %eax"? The
> latter form would not be using the virtual address translation&checking logic.
>
> > > Sometime in the future CPUs will be performing static analysis
> > > of code as long as 100-1000 instructions, which might be
> > > running in parallel to normal instruction execution on
> > > separate special-purpose cores built for solving such a task efficiently.
> >
> > I suppose someone could fire up their old Transmeta tomorrow and prove you correct.
>
> Let's give this matter a very clear interpretation:
>
> Transmeta designs were in-order VLIW CPUs, in year 2000. That's basically what Pentium/PentiumMMX
> with instruction pairing were capable of in years 1993/1996.
>
> Some other, less important, notes:
>
> - There is very low probability that a VLIW CPU could (at the same power limit and
> chip size) outperform an out-of-order CPU (Pentium Pro or AMD K5 and successors).
>
> - The size of an x86 instruction decode unit decoding an equivalent number of instructions per clock
> as Transmeta did per clock is not excessively large compared to the size of the rest of an x86 CPU.
>
> - The term used nowadays in place of instruction pairing is
> instruction fusion. Fusion sounds much cooler than pairing.
Fusion is stronger than pairing. Pairing is purely a restriction (or perhaps better an anti-restriction, a flexibility) on issue.
Fusion is a resource amplification, a tying together of two (or more) instructions as a single unit for the purposes of how various limited resources (eg ROB slots, physical registers, issue queue slots, ...) are used.
Trying to be more precise about the difference than this is hopeless because of course the constraints you are trying to work around are ver different for OoO than IO.
Your Transmeta example is an interesting way of looking at it, but I'd put the issue more as that there remain a variety of options available for OoO "resource amplification" that have been discussed academically, but have not yet been fully explored industrially. One of these is ways to handle register rename within loops. The basic idea, as I understand it, is
- register rename is one of the hottest parts of the OoO pipeline, frequently acting as THE constraint on how wide the pipe can go (along with being literally hot; burning a lot power)
- so how can we improve this, either allowing for more renames per cycle, or making them lower energy, without impacting cycle time?
- how about for long-running loops we extract the "essence" of the renaming in the loop body, and reimplement that in some fashion that's better along our two metrics?
The easiest way to do this, perhaps the first step, could be something as simple as this:
- we know that most of the time say a 4-wide CPU won't actually need to rename 4 int (or 4 fp) registers in a cycle. There may be a store in there, a mix of fp and int, a compare or branch. But (again, cycle time constraints) you may have to throttle things so that each cycle you only pump 4 instructions through rename because you don't have time to triage how renames are required for reach register pool by the particular instruction mix.
But IF you have a long-running loop, you can perhaps afford to take a cycle or two to analyze the loop kernel, count how many renames are required for each register pool, pack instructions appropriately, and bump things up to say an average of 7 renames per cycle.
If you want, there are then more aggressive ways to go down this path, but I suspect these are probably too fragile to be interesting for most "generic code". (Though who knows? One's intuitions about "average code" and "average behavior" are frequently wrong...)
Of course this now requires (at least some part of) the rest of your pipeline to be able to sustain 7-wide. Issue queue needs to be able to eat and spit out 7, loop buffer/trace cache same, retire/complete same. But perhaps they are amenable to the same sorts of ideas -- if you can tag the code appropriately, you may be able to get around "broad" constraints that have to be in place for generic code because these code stretches have been vetted as guaranteed to not to exceed those constraints in their most narrow precise fashion.
> anon2 (anon.delete@this.anon.com) on July 13, 2020 7:25 pm wrote:
> > ⚛ (0xe2.0x9a.0x9b.delete@this.gmail.com) on July 13, 2020 4:02 am wrote:
> > > Veedrac (ignore.delete@this.this.com) on July 12, 2020 4:21 pm wrote:
> > > > Intel's stagnation has made many people think of this as where we're at: single threaded
> > > > performance is stagnant because scaling isn't practical any more. I'm now certain this isn't remotely true.
> > >
> > > Maybe improvements in single-threaded IPC better fit a curve of punctuated equilibria
> > > rather than fitting the curve of steady gradual improvements over time.
> > >
> > > AMD, Intel and many others haven't tried to go the path of
> > > reducing the amount of redundant/repetitious dynamic
> > > computations in the CPU's out-of-order engine.
> >
> > How do you know?
>
> Is there some indication that AMD/Intel are reducing the amount of redundant/repetitious dynamic computations
> in Zen/SunnyCove's by storing that kind of information in the µop cache for example, such as:
>
> loop:
> ...
> mov -16(%rbp), %eax
> ...
> jne loop
>
> where "mov -16(%rbp), %eax" is replaced by "mov -16(%rbp_translated), %eax"? The
> latter form would not be using the virtual address translation&checking logic.
>
> > > Sometime in the future CPUs will be performing static analysis
> > > of code as long as 100-1000 instructions, which might be
> > > running in parallel to normal instruction execution on
> > > separate special-purpose cores built for solving such a task efficiently.
> >
> > I suppose someone could fire up their old Transmeta tomorrow and prove you correct.
>
> Let's give this matter a very clear interpretation:
>
> Transmeta designs were in-order VLIW CPUs, in year 2000. That's basically what Pentium/PentiumMMX
> with instruction pairing were capable of in years 1993/1996.
>
> Some other, less important, notes:
>
> - There is very low probability that a VLIW CPU could (at the same power limit and
> chip size) outperform an out-of-order CPU (Pentium Pro or AMD K5 and successors).
>
> - The size of an x86 instruction decode unit decoding an equivalent number of instructions per clock
> as Transmeta did per clock is not excessively large compared to the size of the rest of an x86 CPU.
>
> - The term used nowadays in place of instruction pairing is
> instruction fusion. Fusion sounds much cooler than pairing.
Fusion is stronger than pairing. Pairing is purely a restriction (or perhaps better an anti-restriction, a flexibility) on issue.
Fusion is a resource amplification, a tying together of two (or more) instructions as a single unit for the purposes of how various limited resources (eg ROB slots, physical registers, issue queue slots, ...) are used.
Trying to be more precise about the difference than this is hopeless because of course the constraints you are trying to work around are ver different for OoO than IO.
Your Transmeta example is an interesting way of looking at it, but I'd put the issue more as that there remain a variety of options available for OoO "resource amplification" that have been discussed academically, but have not yet been fully explored industrially. One of these is ways to handle register rename within loops. The basic idea, as I understand it, is
- register rename is one of the hottest parts of the OoO pipeline, frequently acting as THE constraint on how wide the pipe can go (along with being literally hot; burning a lot power)
- so how can we improve this, either allowing for more renames per cycle, or making them lower energy, without impacting cycle time?
- how about for long-running loops we extract the "essence" of the renaming in the loop body, and reimplement that in some fashion that's better along our two metrics?
The easiest way to do this, perhaps the first step, could be something as simple as this:
- we know that most of the time say a 4-wide CPU won't actually need to rename 4 int (or 4 fp) registers in a cycle. There may be a store in there, a mix of fp and int, a compare or branch. But (again, cycle time constraints) you may have to throttle things so that each cycle you only pump 4 instructions through rename because you don't have time to triage how renames are required for reach register pool by the particular instruction mix.
But IF you have a long-running loop, you can perhaps afford to take a cycle or two to analyze the loop kernel, count how many renames are required for each register pool, pack instructions appropriately, and bump things up to say an average of 7 renames per cycle.
If you want, there are then more aggressive ways to go down this path, but I suspect these are probably too fragile to be interesting for most "generic code". (Though who knows? One's intuitions about "average code" and "average behavior" are frequently wrong...)
Of course this now requires (at least some part of) the rest of your pipeline to be able to sustain 7-wide. Issue queue needs to be able to eat and spit out 7, loop buffer/trace cache same, retire/complete same. But perhaps they are amenable to the same sorts of ideas -- if you can tag the code appropriately, you may be able to get around "broad" constraints that have to be in place for generic code because these code stretches have been vetted as guaranteed to not to exceed those constraints in their most narrow precise fashion.
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 |