Part of the exploration that I omitted in my prior email is to enhance C2s calling convention to support vector arguments, thereby enabling the passing of vector arguments as vector registers. (This might also shed some light on how we might support Panama native calls too.)
The constant species might come along for the ride as a side-argument with the “bag of bits” e.g. an ad-hoc form of specialization. Hard to say exactly until we experiment. Paul. > On Sep 11, 2022, at 7:04 AM, [email protected] wrote: > > ----- Original Message ----- >> From: "Paul Sandoz" <[email protected]> >> To: "Remi Forax" <[email protected]> >> Cc: "Brian Goetz" <[email protected]>, "valhalla-spec-experts" >> <[email protected]> >> Sent: Thursday, September 8, 2022 1:10:26 AM >> Subject: Re: What we have lost ? > >> The Vector API is I think a proof point that ref projection can be acceptable >> and can work. >> >> The Vector API implementation currently behaves approximately as if a vector >> instance (whose concrete class is private) is a ref to a value object. The C2 >> compiler performs aggressive unboxing and mapping "payloads" (analogous to >> value objects) vectors hold to vector registers, rather than scalarizing the >> element “overlay” or view over the payload described by the vector’s shape >> and >> element type (the species). >> >> In this current model we generally don’t recommend storing vector instances >> in >> the heap (there are exceptions to that rule for constants), and instead >> vectors >> are loaded from or stored to memory containers such as arrays, byte buffers, >> or >> memory segments. After a few iterations of the API and implementation its >> starting to work rather well at generating efficient vectorized code on >> supporting hardware. >> >> >> We are currently early in the process of exploring alignment of the Vector >> API >> with Valhalla where: >> >> 1. the private concrete vector classes are value classes whose .val type is >> private; and >> 2. a vector value class has a "payload" field whose type is a value type. >> >> The "payload" is a non-atomic "bag of bits" e.g. values types of Bits256.val, >> Bits128.val etc, which would not be exposed in the public Vector API. So no >> utterance of .val is expected in this model. The API remains the same as it >> does today. >> >> We could decide the value classes of those “bag of bits” could be public >> classes, and developers may interact with those using the .val. Unsure yet. >> As >> we explore and learn more the approach could change. I hope the exploration >> will be informative. > > > The problem of the current API is that it only works if everything is inlined > by C2, otherwise performance is awful. > If a method is not inlined because its assembly code is too big, performance > is awful, if a species is not a constant (some students just forget "final" > when declaring the species as static final), performance is awful, if an > operator (ADD, DIV, etc) is not a constant, performance is awful. > > I'm pretty sure, i've already said that but i believe there is a better API > design that can work even if a method is not inlined, because being sure that > everything is inlined is a hard goal to attain once the code starts to grow. > > For that a vector should be a generic value class parametrized by the vector > species (so the species is always a constant) with the actual species been > private, not visible from the language, an Int128Vector becomes an IntVector > at compile time and an IntVector<Int128Species> at runtime. > > In that world if a method is not inlined and a value class if a ref, you have > nullchecks appearing and those will be hard to see apart taking a look to the > assembly code. > If an IntVector has no ref companion, you eliminate such kind of performance > hiccup. > >> >> Paul. > > Rémi
