Hi Richard,
Apologies as I replied w/o looking for another update on the thread first.
On 10/30/24 11:35, Richard Sandiford wrote:
I'm not saying that the algorithm gets the decision right for cactu
when tuning for in-order CPU X and running on that same CPU X.
But it seems like th
Vineet Gupta writes:
> On 10/30/24 10:25, Jeff Law wrote:
>> On 10/30/24 9:31 AM, Richard Sandiford wrote:
>>> That might need some finessing of the name. But I think the concept
>>> is right. I'd rather base the hook (or param) on a general concept
>>> like that rather than a specific "wide vs
On 10/30/24 10:25, Jeff Law wrote:
> On 10/30/24 9:31 AM, Richard Sandiford wrote:
>> That might need some finessing of the name. But I think the concept
>> is right. I'd rather base the hook (or param) on a general concept
>> like that rather than a specific "wide vs narrow" thing.
> Agreed. Na
Jeff Law writes:
> On 10/30/24 9:31 AM, Richard Sandiford wrote:
>
>>
>> OK (and yeah, I can sympathise). But I think there's an argument that,
>> if you're scheduling for one in-order core using the pipeline of an
>> unrelated core, that's effectively scheduling for the core as though
>> it wer
On 10/30/24 9:31 AM, Richard Sandiford wrote:
OK (and yeah, I can sympathise). But I think there's an argument that,
if you're scheduling for one in-order core using the pipeline of an
unrelated core, that's effectively scheduling for the core as though
it were out-of-order. In other words
Jeff Law writes:
> On 10/30/24 8:44 AM, Richard Sandiford wrote:
>
>>> But the data from the BPI (spacemit k1 chip) is an in-order core.
>>> Granted we don't have a good model of its pipeline, but it's definitely
>>> in-order.
>>
>> Damn :) (I did try to clarify what was being tested earlier, bu
On 10/30/24 8:44 AM, Richard Sandiford wrote:
But the data from the BPI (spacemit k1 chip) is an in-order core.
Granted we don't have a good model of its pipeline, but it's definitely
in-order.
Damn :) (I did try to clarify what was being tested earlier, but the
response wasn't clear.)
So
Jeff Law writes:
> On 10/30/24 4:05 AM, Richard Sandiford wrote:
>> Vineet Gupta writes:
>>> On 10/29/24 11:51, Wilco Dijkstra wrote:
Hi Vineet,
> I agree the NARROW/WIDE stuff is obfuscating things in technicalities.
Is there evidence this change would make things significantly wor
On 10/30/24 4:05 AM, Richard Sandiford wrote:
Vineet Gupta writes:
On 10/29/24 11:51, Wilco Dijkstra wrote:
Hi Vineet,
I agree the NARROW/WIDE stuff is obfuscating things in technicalities.
Is there evidence this change would make things significantly worse for
some targets?
Honestly I
Vineet Gupta writes:
> On 10/29/24 11:51, Wilco Dijkstra wrote:
>> Hi Vineet,
>>> I agree the NARROW/WIDE stuff is obfuscating things in technicalities.
>> Is there evidence this change would make things significantly worse for
>> some targets?
>
> Honestly I don't think this needs to be behind a
On 10/29/24 1:14 PM, Vineet Gupta wrote:
On 10/29/24 11:51, Wilco Dijkstra wrote:
Hi Vineet,
I agree the NARROW/WIDE stuff is obfuscating things in technicalities.
Is there evidence this change would make things significantly worse for
some targets?
Honestly I don't think this needs to be
On 10/29/24 10:57 AM, Vineet Gupta wrote:
Certainly open to more ideas on the naming, which I think will impact
the documentation & comments as well.
And to be 100% clear, no concerns with the behavior of the patch, it's
really just the naming convention, documentation/comments.
Thoughts?
On 10/29/24 11:51, Wilco Dijkstra wrote:
> Hi Vineet,
>> I agree the NARROW/WIDE stuff is obfuscating things in technicalities.
> Is there evidence this change would make things significantly worse for
> some targets?
Honestly I don't think this needs to be behind any toggle or made optional at
Hi Vineet,
> I agree the NARROW/WIDE stuff is obfuscating things in technicalities.
Is there evidence this change would make things significantly worse for
some targets? I did a few runs on Neoverse V2 with various options and
it looks beneficial both for integer and FP. On the example and option
On 10/29/24 08:05, Jeff Law wrote:
> On 10/20/24 1:40 PM, Vineet Gupta wrote:
>> Pressure senstive scheduling seems to prefer "wide" schedules with more
>> parallelism tending to more spills. This works better for in-order
>> cores [1][2].
> I'm not really sure I'd characterize it that way, but I c
On 10/20/24 1:40 PM, Vineet Gupta wrote:
Pressure senstive scheduling seems to prefer "wide" schedules with more
parallelism tending to more spills. This works better for in-order
cores [1][2].
I'm not really sure I'd characterize it that way, but I can also see how
you got to the wide vs nar
16 matches
Mail list logo
