On Fri, 20 Dec 2024 12:54:54 PST (-0800), jeffreya...@gmail.com wrote:
On 12/20/24 9:48 AM, Palmer Dabbelt wrote:
On Thu, 19 Dec 2024 15:01:26 PST (-0800), jeffreya...@gmail.com wrote:
On 12/19/24 3:08 PM, Palmer Dabbelt wrote:
I agree lacking B and V makes us very clearly uncompetitive in the space
where these sort of things matter (ie, binary compatible distros and
long term stability type things) -- the gap is just too big to close by
doing clever things in the hardware. Maybe just B and V isn't enough,
it's hard to tell, but lacking them seems pretty clearly uncompetitive.
I'm not sure B is so scary on the SW side of things, it's been mostly
performance issues we've been fixing. V is huge, though, and we've
generally found a bunch of V-related functional codegen bugs. Without
reliable hardware to test against (and do distro builds and such) it
just seems premature to declare that being as stable as the other ports
on the list.
It wouldn't take much to push me into agreeing to B -- it's not scary in
any way. There's just notable systems out there that don't implement B,
but I wouldn't mind leaving them behind for this change.
V has real performance concerns. I haven't tested it performance-wise
on the BPI recently, but when I last did the general rule of thumb was
the more vector you did, the worse it performed *especially* for FP.
Yep. TBH that's actually my biggest worry here: it might be that just V
isn't enough, which means we have another few generations of HW before
all the V add-on extensions coalesce into something that's widely
implemented. I'm not really sure there, though -- the HW guys can be
pretty clever so maybe V gets us close enough to be interesting.
Well, I think Robin and I would argue that V can be made to perform. We
see that with our design. But that's because Robin & others have been
focused on the performance for months. The gains that have been made
have been significant and have brought the design & codegen to a point
where it performs largely at expectation. But it's also the case that
our design is not generally available....
That's the problem with this HW stuff, the timelines are just so long to
get anything out and visible that it's hard to tell what the actual
state of the world is.
I don't doubt significant gains could be made that would make V behave
better on widely available designs. They don't have the option of uarch
adjustments, so the upside is limited by that. But with a good
understanding of the uarch and good PMU data significant gains almost
certainly could be made.
Yep, and I think all of the designs that went through without SW
feedback are going to need a lot of work to get even reasonable
performance out of. I don't think there's really anything V (or RISC-V)
specific there, it's just how that design methodology ends up, we're
just seeing it on the V side of things because that's the first
complicated part of RISC-V.
Point being I do think V is viable and will continue to improve as the
feedback loops become better established.
That'd be great, certainly way better than having to wait for another
round of ISA design. Hopefully I'm just seeing more of the results of
the wrong way of doing things and that's overly coloring things, it's my
first round of this so I don't really know how it all fits together.
I guess we'll just have to wait and see when the HW starts to show up ;)
jeff
