Liste des Groupes | Revenir à c arch |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:I guess. I am actually assuming that passing arguments in memory is more expensive than passing them in registers. I don't think that is controversial.On 1/6/2025 6:11 PM, Waldek Hebisch wrote:Some comments to this:MitchAlsup1 <mitchalsup@aol.com> wrote:>>I also think code would be a bit more efficient if there more registers>
available for parameter passing and as scratch registers - perhaps 6
would make more sense.
Basically, here, there is competing pressure between the compiler
needing a handful of preserved registers, and the compiler being
more efficient if there were more argument/result passing registers.
>
My 66000 ABI has 8 argument registers, 7 temporary registers, 14
preserved registers, a FP, and a SP. IP is not part of the register
file. My ABI has a note indicating that the aggregations can be
altered, just that I need a good reason to change.
>
I looked high and low for codes using more than 8 arguments and
returning aggregates larger than 8 double words, and about the
only things I found were a handful of []print[]() calls.
I meet such code with reasonable frequency. I peeked semi
randomly into Lapack. First routine that I looked at had
8 arguments, so within your limit. Second is:
>
SUBROUTINE ZUNMR3( SIDE, TRANS, M, N, K, L, A, LDA, TAU, C, LDC,
$ WORK, INFO )
>
which has 13 arguments.
>
Large number of arguments is typical in old style Fortran numeric
code.
While there has been much discussion down thread relating to Waldek's
other points, there hasn't been much about these.
>
So, some questions. Has Lapack (and the other old style Fortran numeric
code that Waldek mentioned) lost its/their importance as a major user of
CPU cycles? Or do these subroutines consume so many CPU cycles that the
overhead of the large number of parameters is lost in the noise? Or is
there some other explanation for Mitch not considering their importance?
You are implicitely assuming that passing large number of
arguments is expensive.
Of course, if you can do the job withI agree with your example below, which I snipped. My comment was more about the how the system implements argument passing (i.e. the number of registers used for the purpose) than about source code changes (fewer calls with more arguments versus more calls with fewer arguments). Specifically, I was not suggesting changing the source code to reduce the number of arguments.
smaller number of arguments, then there may be some saving.
However, large number of arguments is partially to increase
performance.
Les messages affichés proviennent d'usenet.