By: AM (myname4rwt.delete@this.jee-male.com), August 17, 2018 1:32 pm
Room: Moderated Discussions
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on August 17, 2018 11:20 am wrote:
> Michael S (already5chosen.delete@this.yahoo.com) on August 17, 2018 3:13 am wrote:
> >
> > I beleive it when I see it.
> > This particular design team promised power efficient cores in the past. But until now never delivered.
>
> "This particular team"? I don't recall a single design (ARM
> or otherwise) that actually lived up to the promises.
>
> It may not be as bad as the ia64 promises always were, so Intel has actually been one of
> worst offenders, but the "future design" numbers I've seen have always been some horribly
> bad simulation result that don't take the memory pipeline or the TLB into account, and seem
> to compare some simulated Spec numbers against actual real numbers. Or something.
>
> Even if the design itself is finalized, real hardware is simply something else. Because it turns out that
> the core is just a small part of the equation if you didn't actually have a real memory controller and
> real DRAM, but you just plugged in some optimistic numbers for "this is what the memory could do".
>
> And then you compare with some existing chip with not "could do", but "actually
> does", and you look really damn good. But only in simulation - even if the simulation
> is supposedly cycle accurate (or, more commonly, "at least close to it").
>
> So yeah, I'm with you on wanting actual measured numbers. Both for power and performance.
> And even then it's obviously going to be marketing that cherry-picks the numbers, but at
> least you can make some judgments by the actual benchmarks they chose to mention.
>
> Before that it seems to be almost entirely made up.
>
> Maybe ARM has gotten to the point where the changes are so incremental and well-understood that the
> expected numbers are actually fairly close to reality. But the promised big leap makes me doubt that.
> Whenever you promise some big leap, my gut feel is "ok, let's wait for reality to hit".
>
> So yeah, I'd love to see an actual good A76 design. One with an actual good memory subsystem and TLB
> fill and reasonable IO. Something that actually would work in a laptop (or something like a NUC).
>
> Because dammit, I want an ARM box that I can actually build and test on.
> Not the "yet another device that can do mobile loads and run GB".
>
> Linus
But you do realize that perf of any uarch -- no matter how great it is -- can be artificially constrained by a ton of factors completely out of control of both uarch and the team who designed it, like end product designers' artificially low (not even necessarily thermally constrained) highest clock, or worse-than-should-be memory lat/bw or piss-poor dvfs config (as was the notorious case with Exynos 9810)?
Since you surely do, I'm actually surprized to see you say designs never live up to promises, especially given your tenue at Transmeta -- of course you're right that certain teams practice misleading projections, but it's also true that any perfectly honest design team in the world, ARM or not, doesn't have to artificially constrain neither simulations nor real silicon on their dev boards in whatever above-mentioned and other ways manufacturers of end products do on a routine basis (case in point is not just said Exynos 9810, but also recent 2018 MacBook Pro where Apple screwed up PL1/PL2 values and the time constants -- had they erred not by 2x, but by some 10-20%, the error could have easily gone undetected).
Would you blame Intel for failing to deliver on their promises in this or similar case?
And when it comes to routine overpromising on ARM's part -- I wonder if you actually follow this stuff and read past anti-ARM BS posted here and anywhere else into actual figures. Because a fresh example of their "routine overpromising" is promise of "up to 3 GHz" for A75 which compares with 2.8 GHz in shipping products with SDM845 (perf cores derived from A75) and 2.95 GHz for laptop/hybrid-targeted SDM850 (ditto wrt perf cores), and that gets translated by Alberto-like posters into all sorts of "ARM failed at delivering again, and always will" crap. Yes, ARM's projections tend to turn out higher than specs of shipping products, but God is in the detail.
I agree completely with you that well-designed, unconstrained in whatever silly manner end products would be nice. So if you want one, why don't you actually try doing something, like contacting people to lend you a proper ARM dev system, Linus? I bet you might even get some for free -- just ask.
> Michael S (already5chosen.delete@this.yahoo.com) on August 17, 2018 3:13 am wrote:
> >
> > I beleive it when I see it.
> > This particular design team promised power efficient cores in the past. But until now never delivered.
>
> "This particular team"? I don't recall a single design (ARM
> or otherwise) that actually lived up to the promises.
>
> It may not be as bad as the ia64 promises always were, so Intel has actually been one of
> worst offenders, but the "future design" numbers I've seen have always been some horribly
> bad simulation result that don't take the memory pipeline or the TLB into account, and seem
> to compare some simulated Spec numbers against actual real numbers. Or something.
>
> Even if the design itself is finalized, real hardware is simply something else. Because it turns out that
> the core is just a small part of the equation if you didn't actually have a real memory controller and
> real DRAM, but you just plugged in some optimistic numbers for "this is what the memory could do".
>
> And then you compare with some existing chip with not "could do", but "actually
> does", and you look really damn good. But only in simulation - even if the simulation
> is supposedly cycle accurate (or, more commonly, "at least close to it").
>
> So yeah, I'm with you on wanting actual measured numbers. Both for power and performance.
> And even then it's obviously going to be marketing that cherry-picks the numbers, but at
> least you can make some judgments by the actual benchmarks they chose to mention.
>
> Before that it seems to be almost entirely made up.
>
> Maybe ARM has gotten to the point where the changes are so incremental and well-understood that the
> expected numbers are actually fairly close to reality. But the promised big leap makes me doubt that.
> Whenever you promise some big leap, my gut feel is "ok, let's wait for reality to hit".
>
> So yeah, I'd love to see an actual good A76 design. One with an actual good memory subsystem and TLB
> fill and reasonable IO. Something that actually would work in a laptop (or something like a NUC).
>
> Because dammit, I want an ARM box that I can actually build and test on.
> Not the "yet another device that can do mobile loads and run GB".
>
> Linus
But you do realize that perf of any uarch -- no matter how great it is -- can be artificially constrained by a ton of factors completely out of control of both uarch and the team who designed it, like end product designers' artificially low (not even necessarily thermally constrained) highest clock, or worse-than-should-be memory lat/bw or piss-poor dvfs config (as was the notorious case with Exynos 9810)?
Since you surely do, I'm actually surprized to see you say designs never live up to promises, especially given your tenue at Transmeta -- of course you're right that certain teams practice misleading projections, but it's also true that any perfectly honest design team in the world, ARM or not, doesn't have to artificially constrain neither simulations nor real silicon on their dev boards in whatever above-mentioned and other ways manufacturers of end products do on a routine basis (case in point is not just said Exynos 9810, but also recent 2018 MacBook Pro where Apple screwed up PL1/PL2 values and the time constants -- had they erred not by 2x, but by some 10-20%, the error could have easily gone undetected).
Would you blame Intel for failing to deliver on their promises in this or similar case?
And when it comes to routine overpromising on ARM's part -- I wonder if you actually follow this stuff and read past anti-ARM BS posted here and anywhere else into actual figures. Because a fresh example of their "routine overpromising" is promise of "up to 3 GHz" for A75 which compares with 2.8 GHz in shipping products with SDM845 (perf cores derived from A75) and 2.95 GHz for laptop/hybrid-targeted SDM850 (ditto wrt perf cores), and that gets translated by Alberto-like posters into all sorts of "ARM failed at delivering again, and always will" crap. Yes, ARM's projections tend to turn out higher than specs of shipping products, but God is in the detail.
I agree completely with you that well-designed, unconstrained in whatever silly manner end products would be nice. So if you want one, why don't you actually try doing something, like contacting people to lend you a proper ARM dev system, Linus? I bet you might even get some for free -- just ask.
Topic | Posted By | Date |
---|---|---|
ARM turns to a god and a hero | AM | 2018/08/16 08:32 AM |
ARM turns to a god and a hero | Maynard Handley | 2018/08/16 08:41 AM |
ARM turns to a god and a hero | Doug S | 2018/08/16 10:11 AM |
ARM turns to a god and a hero | Geoff Langdale | 2018/08/16 10:59 PM |
ARM turns to a god and a hero | dmcq | 2018/08/17 04:12 AM |
ARM is somewhat misleading | Adrian | 2018/08/16 10:56 PM |
It's marketing material | Gabriele Svelto | 2018/08/17 12:00 AM |
It's marketing material | Michael S | 2018/08/17 02:13 AM |
It's marketing material | dmcq | 2018/08/17 04:23 AM |
It's marketing material | Andrei Frumusanu | 2018/08/17 06:25 AM |
It's marketing material | Linus Torvalds | 2018/08/17 10:20 AM |
It's marketing material | Groo | 2018/08/17 12:44 PM |
It's marketing material | Doug S | 2018/08/17 01:14 PM |
promises and deliveries | AM | 2018/08/17 01:32 PM |
promises and deliveries | Passing Through | 2018/08/17 02:02 PM |
Just by way of clarification | Passing Through | 2018/08/17 02:15 PM |
Just by way of clarification | AM | 2018/08/18 11:49 AM |
Just by way of clarification | Passing Through | 2018/08/18 12:34 PM |
This ain't the nineties any longer | Passing Through | 2018/08/18 12:54 PM |
This ain't the nineties any longer | Maynard Handley | 2018/08/18 01:50 PM |
This ain't the nineties any longer | Passing Through | 2018/08/18 02:57 PM |
This ain't the nineties any longer | Passing Through | 2018/09/06 01:42 PM |
This ain't the nineties any longer | Maynard Handley | 2018/09/07 03:10 PM |
This ain't the nineties any longer | Passing Through | 2018/09/07 03:48 PM |
This ain't the nineties any longer | Maynard Handley | 2018/09/07 04:22 PM |
Just by way of clarification | Wilco | 2018/08/18 12:26 PM |
Just by way of clarification | Passing Through | 2018/08/18 12:39 PM |
Just by way of clarification | none | 2018/08/18 09:52 PM |
Just by way of clarification | dmcq | 2018/08/19 07:32 AM |
Just by way of clarification | none | 2018/08/19 07:54 AM |
Just by way of clarification | dmcq | 2018/08/19 10:24 AM |
Just by way of clarification | none | 2018/08/19 10:52 AM |
Just by way of clarification | Gabriele Svelto | 2018/08/19 05:41 AM |
Just by way of clarification | Passing Through | 2018/08/19 08:25 AM |
Whiteboards at Gatwick airport anyone? | Passing Through | 2018/08/20 03:24 AM |
It's marketing material | Michael S | 2018/08/18 10:12 AM |
It's marketing material | Brett | 2018/08/18 04:22 PM |
It's marketing material | Brett | 2018/08/18 04:33 PM |
It's marketing material | Adrian | 2018/08/19 12:21 AM |
A76 | AM | 2018/08/17 01:45 PM |
A76 | Michael S | 2018/08/18 10:20 AM |
A76 | AM | 2018/08/18 11:39 AM |
A76 | Michael S | 2018/08/18 11:49 AM |
A76 | AM | 2018/08/18 12:06 PM |
A76 | Doug S | 2018/08/18 12:43 PM |
A76 | Maynard Handley | 2018/08/18 01:42 PM |
A76 | Maynard Handley | 2018/08/18 03:22 PM |
Why write zeros when one can use metadata? | Paul A. Clayton | 2018/08/18 05:19 PM |
Why write zeros when one can use metadata? | Maynard Handley | 2018/08/19 10:12 AM |
Dictionary compress might apply to memcopy | Paul A. Clayton | 2018/08/19 12:45 PM |
Instructions for zeroing | Konrad Schwarz | 2018/08/30 05:37 AM |
Instructions for zeroing | Maynard Handley | 2018/08/30 07:41 AM |
Instructions for zeroing | Adrian | 2018/08/30 10:37 AM |
dcbz -> dcbzl (was: Instructions for zeroing) | hobold | 2018/08/31 12:50 AM |
dcbz -> dcbzl (was: Instructions for zeroing) | dmcq | 2018/09/01 04:28 AM |
A76 | Travis | 2018/08/19 10:36 AM |
A76 | Maynard Handley | 2018/08/19 11:22 AM |
A76 | Travis | 2018/08/19 01:07 PM |
A76 | Maynard Handley | 2018/08/19 05:24 PM |
Remote atomics | matthew | 2018/08/19 11:51 AM |
Remote atomics | Michael S | 2018/08/19 12:58 PM |
Remote atomics | matthew | 2018/08/19 01:32 PM |
Remote atomics | Michael S | 2018/08/19 01:36 PM |
Remote atomics | matthew | 2018/08/19 01:48 PM |
Remote atomics | Michael S | 2018/08/19 02:16 PM |
Remote atomics | Ricardo B | 2018/08/20 09:05 AM |
Remote atomics | dmcq | 2018/08/19 01:33 PM |
Remote atomics | Travis | 2018/08/19 01:32 PM |
Remote atomics | Michael S | 2018/08/19 01:46 PM |
Remote atomics | Travis | 2018/08/19 04:35 PM |
Remote atomics | Michael S | 2018/08/20 02:29 AM |
Remote atomics | matthew | 2018/08/19 06:58 PM |
Remote atomics | anon | 2018/08/19 11:59 PM |
Remote atomics | Travis | 2018/08/20 09:26 AM |
Remote atomics | Travis | 2018/08/20 08:57 AM |
Remote atomics | Linus Torvalds | 2018/08/20 03:29 PM |
Fitting time slices to execution phases | Paul A. Clayton | 2018/08/21 08:09 AM |
Fitting time slices to execution phases | Linus Torvalds | 2018/08/21 01:34 PM |
Fitting time slices to execution phases | Linus Torvalds | 2018/08/21 02:31 PM |
Fitting time slices to execution phases | Gabriele Svelto | 2018/08/21 02:54 PM |
Fitting time slices to execution phases | Linus Torvalds | 2018/08/21 03:26 PM |
Fitting time slices to execution phases | Travis | 2018/08/21 03:21 PM |
Fitting time slices to execution phases | Linus Torvalds | 2018/08/21 03:39 PM |
Fitting time slices to execution phases | Travis | 2018/08/21 03:59 PM |
Fitting time slices to execution phases | Linus Torvalds | 2018/08/21 04:13 PM |
Fitting time slices to execution phases | anon | 2018/08/21 03:27 PM |
Fitting time slices to execution phases | Linus Torvalds | 2018/08/21 05:02 PM |
Fitting time slices to execution phases | Etienne | 2018/08/22 01:28 AM |
Fitting time slices to execution phases | Gabriele Svelto | 2018/08/22 02:07 PM |
Fitting time slices to execution phases | Travis | 2018/08/22 03:00 PM |
Fitting time slices to execution phases | anon | 2018/08/22 05:52 PM |
Fitting time slices to execution phases | Travis | 2018/08/21 03:37 PM |
Is preventing misuse that complex? | Paul A. Clayton | 2018/08/23 04:42 AM |
Is preventing misuse that complex? | Linus Torvalds | 2018/08/23 11:46 AM |
Is preventing misuse that complex? | Travis | 2018/08/23 12:29 PM |
Is preventing misuse that complex? | Travis | 2018/08/23 12:33 PM |
Is preventing misuse that complex? | Jeff S. | 2018/08/24 06:57 AM |
Is preventing misuse that complex? | Travis | 2018/08/24 07:47 AM |
Is preventing misuse that complex? | Linus Torvalds | 2018/08/23 01:30 PM |
Is preventing misuse that complex? | Travis | 2018/08/23 02:11 PM |
Is preventing misuse that complex? | Linus Torvalds | 2018/08/24 12:00 PM |
Is preventing misuse that complex? | Gabriele Svelto | 2018/08/24 12:25 PM |
Is preventing misuse that complex? | Linus Torvalds | 2018/08/24 12:33 PM |
Fitting time slices to execution phases | Travis | 2018/08/21 02:54 PM |
rseq: holy grail rwlock? | Travis | 2018/08/21 02:18 PM |
rseq: holy grail rwlock? | Linus Torvalds | 2018/08/21 02:59 PM |
rseq: holy grail rwlock? | Travis | 2018/08/21 03:27 PM |
rseq: holy grail rwlock? | Linus Torvalds | 2018/08/21 04:10 PM |
rseq: holy grail rwlock? | Travis | 2018/08/21 05:21 PM |
ARM design houses | Michael S | 2018/08/21 04:07 AM |
ARM design houses | Wilco | 2018/08/22 11:38 AM |
ARM design houses | Michael S | 2018/08/22 01:21 PM |
ARM design houses | Wilco | 2018/08/22 02:23 PM |
ARM design houses | Michael S | 2018/08/29 12:58 AM |
Qualcomm's core naming scheme really, really sucks | Heikki Kultala | 2018/08/29 01:19 AM |
A76 | Maynard Handley | 2018/08/18 01:07 PM |
A76 | Michael S | 2018/08/18 01:32 PM |
A76 | Maynard Handley | 2018/08/18 01:52 PM |
A76 | Michael S | 2018/08/18 02:04 PM |
ARM is somewhat misleading | juanrga | 2018/08/17 12:20 AM |
Surprised?? | Alberto | 2018/08/17 12:52 AM |
Surprised?? | Alberto | 2018/08/17 01:10 AM |
Surprised?? | none | 2018/08/17 01:46 AM |
Garbage talk | Andrei Frumusanu | 2018/08/17 06:30 AM |
Garbage talk | Michael S | 2018/08/17 06:43 AM |
Garbage talk | Andrei Frumusanu | 2018/08/17 08:51 AM |
Garbage talk | Michael S | 2018/08/18 10:29 AM |
Garbage talk | Adrian | 2018/08/17 07:28 AM |
Garbage talk | Alberto | 2018/08/17 08:20 AM |
Garbage talk | Andrei Frumusanu | 2018/08/17 08:48 AM |
Garbage talk | Adrian | 2018/08/17 09:17 AM |
Garbage talk | Andrei Frumusanu | 2018/08/17 09:36 AM |
Garbage talk | Adrian | 2018/08/17 01:53 PM |
Garbage talk | Andrei Frumusanu | 2018/08/17 11:17 PM |
More like a religion he?? ARM has an easy life :) | Alberto | 2018/08/17 08:13 AM |
More like a religion he?? ARM has an easy life :) | Andrei Frumusanu | 2018/08/17 08:34 AM |
More like a religion he?? ARM has an easy life :) | Alberto | 2018/08/17 09:03 AM |
More like a religion he?? ARM has an easy life :) | Andrei Frumusanu | 2018/08/17 09:43 AM |
More like a religion he?? ARM has an easy life :) | Doug S | 2018/08/17 01:17 PM |
15W phone SoCs | AM | 2018/08/17 02:04 PM |
More like a religion he?? ARM has an easy life :) | Maynard Handley | 2018/08/17 11:29 AM |
my future stuff will be better than your old stuff, hey I'm a god at last (NT) | Eric Bron | 2018/08/18 02:34 AM |
my future stuff will be better than your old stuff, hey I'm a god at last | none | 2018/08/18 07:34 AM |