On Monday, July 31, 2023 at 1:45:32 PM UTC-5, BGB wrote:
> On 7/31/2023 12:00 PM, MitchAlsup wrote:
> > On Monday, July 31, 2023 at 2:09:27 AM UTC-5, Terje Mathisen wrote:
> >> Thomas Koenig wrote:
> >>> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
> >>>
> >>>> Every performance improvement project for an interpreter
> >>>> (e.g. <https://lwn.net/Articles/930705/>) shows that the performance
> >>>> of the interpreter matters. The fact that people perform performance
> >>>> measurements shows this, too.
> >>>
> >>> Widely-used interpeted languages such as Python or Matlab are
> >>> known to be as slow as molasses when they do not call highly-
> >>> efficient compiled code. Any improvement (such as the link above)
> >>> is welcome there.
> >>>
> >>> A concept followed by languages like the one used by Julia, which
> >>> uses JIT compilation much more aggressively, seems to be a better
> >>> approach. I have barely glanced at it yet, but it certainly seems
> >>> worth looking into for scientific work.
> >>>
> >> This is what I'm really arguing for: If any real interpreter is doomed
> >> to always be much, much slower than inline binary code, then we need
> >> better ways to (at runtime?) convert the former into the latter, i.e.
> >> JIT optimization of the parts that need it.
> > <
> > {{
> > A real interpreter is going to average DIV 1000
> > Jitting instructions into a trace is going to average DIV 100.
> > A JIT trace is going to average DIV 10
> > }} per interpreted instruction.
> > But here JIT means converting simulated instructions into native
> > instructions with a touch of peepholeing.
> This seems a little pessimistic.
>
> My own past stats were:
> Naive bytecode: ~ 300..1000, depending on the design of the bytecode.
> Dynamic types are slower than static types;
> Stack vs 3R is another factor of 2.
<
Simple RISC instruction interpretation is on the order of 100 instructions
per instruction interpretation. Memory references where you have to update
caches and TLBs are the ones making the average high. Branches are
also expensive if you are keeping ICache and ITLB up to date.
>
<snip>
> Well, and also it would be nice if the operator precedence hierarchy
> were "less stupid".
>
> Like, if it were up to me, say:
> * / %
> + -
> & | ^
> << >>
> == != ...
> && ||
> = += -= ...
<
One does not have to deal with operator precedence when interpreting
non-native ISA (all that crap has been taken care of already.)
>

On 7/31/2023 1:59 PM, MitchAlsup wrote:
> On Monday, July 31, 2023 at 1:45:32 PM UTC-5, BGB wrote:
>> On 7/31/2023 12:00 PM, MitchAlsup wrote:
>>> On Monday, July 31, 2023 at 2:09:27 AM UTC-5, Terje Mathisen wrote:
>>>> Thomas Koenig wrote:
>>>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
>>>>>
>>>>>> Every performance improvement project for an interpreter
>>>>>> (e.g. <https://lwn.net/Articles/930705/>) shows that the performance
>>>>>> of the interpreter matters. The fact that people perform performance
>>>>>> measurements shows this, too.
>>>>>
>>>>> Widely-used interpeted languages such as Python or Matlab are
>>>>> known to be as slow as molasses when they do not call highly-
>>>>> efficient compiled code. Any improvement (such as the link above)
>>>>> is welcome there.
>>>>>
>>>>> A concept followed by languages like the one used by Julia, which
>>>>> uses JIT compilation much more aggressively, seems to be a better
>>>>> approach. I have barely glanced at it yet, but it certainly seems
>>>>> worth looking into for scientific work.
>>>>>
>>>> This is what I'm really arguing for: If any real interpreter is doomed
>>>> to always be much, much slower than inline binary code, then we need
>>>> better ways to (at runtime?) convert the former into the latter, i.e.
>>>> JIT optimization of the parts that need it.
>>> <
>>> {{
>>> A real interpreter is going to average DIV 1000
>>> Jitting instructions into a trace is going to average DIV 100.
>>> A JIT trace is going to average DIV 10
>>> }} per interpreted instruction.
>>> But here JIT means converting simulated instructions into native
>>> instructions with a touch of peepholeing.
>> This seems a little pessimistic.
>>
>> My own past stats were:
>> Naive bytecode: ~ 300..1000, depending on the design of the bytecode.
>> Dynamic types are slower than static types;
>> Stack vs 3R is another factor of 2.
> <
> Simple RISC instruction interpretation is on the order of 100 instructions
> per instruction interpretation. Memory references where you have to update
> caches and TLBs are the ones making the average high. Branches are
> also expensive if you are keeping ICache and ITLB up to date.

For emulating the SH-2, I had a mechanism to mark which pages held
previously decoded instruction traces, and would trigger a trace-flush
if any of these pages were written to (with some special handling to
allow the current trace to "finish gracefully", the I$/trace flush being
handled like a sort of "non-throwing exception").

Early on, I had tried a mechanism to selectively flush traces based on
whether they touched the modified page; but then found it was faster to
simply flush everything and start over from a clean slate whenever this
happened (the JIT was similar; if the JIT cache got full, flush
everything and start over).

For BJX1 and BJX2, the rules were slightly different, and one needs to
trigger an I$ flush manually if any executable code in memory is
modified (otherwise, behavior is undefined; and may result in executing
stale code).

Note that trace dispatch is typically via a sort of set-associative hash
table, with the traces typically also caching pointers to other traces
for direct branches (to limit cases where it needs to fall back to using
the general-case of using the hash table).

In most of my other interpreters, it is more convenient to assume some
variation of a Harvard architecture.

>>
> <snip>
>> Well, and also it would be nice if the operator precedence hierarchy
>> were "less stupid".
>>
>> Like, if it were up to me, say:
>> * / %
>> + -
>> & | ^
>> << >>
>> == != ...
>> && ||
>> = += -= ...
> <
> One does not have to deal with operator precedence when interpreting
> non-native ISA (all that crap has been taken care of already.)

Yeah, at this point I was talking about the language level.
Granted, bytecode or below does not need to care about operator precedence.

Some of my VMs had been designed to use a stack bytecode with the
assumption that it will be translated on load to a 3AC trace-form
internally (as opposed to running the stack ops directly).

Though, this does imply putting some restrictions on how the stack may
be used by the bytecode; but given things like .NET and similar had
similar restrictions, I suspect they were operating under a similar
assumption.

One can similarly, also, have code that is dynamically or 'auto typed'
at the level of the stack bytecode, but the types are already resolved
by the time of the 3AC code; but, this does create a little bit of a
messy situation with "who is responsible for the language-level
type-promotion handling".

In BGBCC, it ended up being handled mostly in the stack-IR to 3AC stage,
which is "not ideal" (in .NET, the front-end dealt with it, and had much
more simplistic / explicit handling of type conversion and promotion in
the backend).

If I were "doing it all again", I might be more inclined to more closely
follow .NET's model in this area...

I had started work on a new (possible) C compiler, but this is likely to
go directly from ASTs to 3AC without an intermediate stack-IR stage.
Well, unless one argues that I should still include such an IR stage.

....

On Monday, July 31, 2023 at 11:34:46 AM UTC-5, Anton Ertl wrote:
> Terje Mathisen <terje.m...@tmsw.no> writes:
> >Thomas Koenig wrote:
> >> A concept followed by languages like the one used by Julia, which
> >> uses JIT compilation much more aggressively, seems to be a better
> >> approach. I have barely glanced at it yet, but it certainly seems
> >> worth looking into for scientific work.
> Julia is interesting in many respects, but it uses a slow compiler
> (IIRC LLVM) plus caching in a JIT-like setting. I.e., when the
> compiler sees new code, you see delays far beyond what you see with
> interpreters or more conventional JITs. This may be a good choice for
> Julia, but I have my doubts that it would gained popularity for a
> language with a different application area.
> >This is what I'm really arguing for: If any real interpreter is doomed
> >to always be much, much slower than inline binary code, then we need
> >better ways to (at runtime?) convert the former into the latter, i.e.
> >JIT optimization of the parts that need it.
> You may think so, but the reality often is: When a language designer
> wants to design an interactive language, the cheap and straightforward
> way is to write an interpreter.
>
> Will you finance the teams that are necessary to implement JIT
> compilers for every newfangled language?
>
> Will you finance the teams necessary to implement JIT compilers for
> those languages that have found a following? That's of course a much
> smaller number of languages, but then, each of these teams will have
> to deal with entrenched usage and may not be able to replace the
> interpreter. Note that Pypy has been started 16 years ago, and yet
> CPython (the slow interpreter) is by far the most popular Python
> implementation.
>
> You can put your hopes in Truffle, and maybe Truffle will change the
> way how aspiring language designers work, but if so, it will be a big
> marketing success.
> >Changing the hardware to make indirect function calls and returns far
> >faster would be nice, but they will always cost a lot more than zero.
> Indirect function calls and returns are fast on modern hardware in the
> common case (except if you work around Spectre with retpolines, then
> they are very slow).
> >I believe conditional branches is the one CPU feature where a naive
> >interpreter (calling a function for each opcode) can be relatively fast:
> >Calculate the new IP with a conditional/predicated move and return, with
> >no branch predictor issues.
> I don't know many interpreters that call a function for each opcode
> (actually only one: PFE); many use a big switch in one function; this
> is better for performance, because more than one virtual-machine
> registers can be passed in real registers. Some are more advanced and
> use techniques like threaded code. In every one of these cases, you
> have an indirect call or indirect branch for every VM instruction, and
> you therefore need indirect branch prediction dearly; compiling an
> interpreter with Spectre v2 to use a retpoline for the indirect
> jumps/calls causes a huge slowdown.
>
> Concerning a VM-level conditional branch, if you use a conditional
> move to set the instruction pointer (IP), yes, you have eliminated
> that branch prediction, but a few instructions later there will be a
> fetch from that IP and then an indirect branch (or indirect call)
> based on the fetched value, and that has to be predicted, and it will
> tend to predict worse than the conditional branch predictor (which is
> tuned for conditional branches). I am not an expert in indirect
> branch predictors in current CPUs, but if the conditional-branch
> history is also used for predicting indirect branches, it may be
> detrimental to eliminate the conditional branch from the
> implementation of the VM-level conditional branch.
>
> There is one technique called selective inlining (aka dynamic
> superinstructions) that eliminates the indirect branches for
> straight-line VM code. In that case a VM-level conditional branch
> only needs an indirect brach in the branch-taken case, but then you
> need a native-code-level conditional branch to skip the indirect
> branch.
>
> E.g., for the Forth code
>
> : foo dup if 1+ then ;
>
> the resulting VM code plus the machine code is (gforth-fast on
> RISC-V):
>
> $3FAA160638 dup 1->2
> 0x0000003fa9e04ede: mv s0,s7
> $3FAA160640 ?branch 2->1
> $3FAA160648 <foo+$20>
> 0x0000003fa9e04ee0: addi s10,s10,24
> 0x0000003fa9e04ee2: ld a5,-8(s10)
> 0x0000003fa9e04ee6: bnez s0,0x3fa9e04eee
> 0x0000003fa9e04ee8: ld a4,0(a5)
> 0x0000003fa9e04eea: mv s10,a5
> 0x0000003fa9e04eec: jr a4
> $3FAA160650 1+ 1->1
> 0x0000003fa9e04eee: addi s7,s7,1
> 0x0000003fa9e04ef0: addi s10,s10,8
> $3FAA160658 ;s 1->1
> 0x0000003fa9e04ef2: ld a6,0(s2)
> 0x0000003fa9e04ef6: addi s2,s2,8
> 0x0000003fa9e04ef8: mv s10,a6
> 0x0000003fa9e04efa: ld a4,0(s10)
> 0x0000003fa9e04efe: jr a4
>
> The two "jr" instructions are the indirect branches. The "bnez"
> branches around the branch-taken case and its indirect branch to the
> code for 1+.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

|> Julia is interesting in many respects

Am wondering about using Julia parse-tree, meta and macro capabilities
to generate assembler source code for various architectures?
E.g using compilation that supports constants, variables and simple loops
then with minimal effort and some template matching generate assembler
or binary source.

Thomas Koenig wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
>
> [...]
>
>> in the case of having non-saved registers
>> that you'd like to use across function calls, I would probably consider
>> writing wrappers for those function calls: The wrapper would do the
>> save, call the actual function, then restore and return.
>
> The discussion on gcc has turned up an interesting option that I had
> overlooked:
>
> '-fipa-ra'
> Use caller save registers for allocation if those registers are not
> used by any called function. In that case it is not necessary to
> save and restore them around calls. This is only possible if
> called functions are part of same compilation unit as current
> function and they are compiled before it.
>
> Enabled at levels '-O2', '-O3', '-Os', however the option is
> disabled if generated code will be instrumented for profiling
> ('-p', or '-pg') or if callee's register usage cannot be known
> exactly (this happens on targets that do not expose prologues and
> epilogues in RTL).
>
> This should also be enabled with LTO.

So this is basically the compiler people doing automatically the same
kind of register optimizations that I do manually in my asm. Nice!

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

MitchAlsup wrote:
> On Monday, July 31, 2023 at 1:45:32 PM UTC-5, BGB wrote:
>> On 7/31/2023 12:00 PM, MitchAlsup wrote:
>>> On Monday, July 31, 2023 at 2:09:27 AM UTC-5, Terje Mathisen wrote:
>>>> Thomas Koenig wrote:
>>>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
>>>>>
>>>>>> Every performance improvement project for an interpreter
>>>>>> (e.g. <https://lwn.net/Articles/930705/>) shows that the performance
>>>>>> of the interpreter matters. The fact that people perform performance
>>>>>> measurements shows this, too.
>>>>>
>>>>> Widely-used interpeted languages such as Python or Matlab are
>>>>> known to be as slow as molasses when they do not call highly-
>>>>> efficient compiled code. Any improvement (such as the link above)
>>>>> is welcome there.
>>>>>
>>>>> A concept followed by languages like the one used by Julia, which
>>>>> uses JIT compilation much more aggressively, seems to be a better
>>>>> approach. I have barely glanced at it yet, but it certainly seems
>>>>> worth looking into for scientific work.
>>>>>
>>>> This is what I'm really arguing for: If any real interpreter is doomed
>>>> to always be much, much slower than inline binary code, then we need
>>>> better ways to (at runtime?) convert the former into the latter, i.e.
>>>> JIT optimization of the parts that need it.
>>> <
>>> {{
>>> A real interpreter is going to average DIV 1000
>>> Jitting instructions into a trace is going to average DIV 100.
>>> A JIT trace is going to average DIV 10
>>> }} per interpreted instruction.
>>> But here JIT means converting simulated instructions into native
>>> instructions with a touch of peepholeing.
>> This seems a little pessimistic.
>>
>> My own past stats were:
>> Naive bytecode: ~ 300..1000, depending on the design of the bytecode.
>> Dynamic types are slower than static types;
>> Stack vs 3R is another factor of 2.
> <
> Simple RISC instruction interpretation is on the order of 100 instructions
> per instruction interpretation. Memory references where you have to update
> caches and TLBs are the ones making the average high. Branches are
> also expensive if you are keeping ICache and ITLB up to date.

It sounds like your numbers are for a CPU emulator, not just an
interpreter of the running code?

Terje

>>
> <snip>
>> Well, and also it would be nice if the operator precedence hierarchy
>> were "less stupid".
>>
>> Like, if it were up to me, say:
>> * / %
>> + -
>> & | ^
>> << >>
>> == != ...
>> && ||
>> = += -= ...
> <
> One does not have to deal with operator precedence when interpreting
> non-native ISA (all that crap has been taken care of already.)
>>
>

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 8/1/2023 9:12 AM, Terje Mathisen wrote:
> MitchAlsup wrote:
>> On Monday, July 31, 2023 at 1:45:32 PM UTC-5, BGB wrote:
>>> On 7/31/2023 12:00 PM, MitchAlsup wrote:
>>>> On Monday, July 31, 2023 at 2:09:27 AM UTC-5, Terje Mathisen wrote:
>>>>> Thomas Koenig wrote:
>>>>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
>>>>>>
>>>>>>> Every performance improvement project for an interpreter
>>>>>>> (e.g. <https://lwn.net/Articles/930705/>) shows that the performance
>>>>>>> of the interpreter matters. The fact that people perform performance
>>>>>>> measurements shows this, too.
>>>>>>
>>>>>> Widely-used interpeted languages such as Python or Matlab are
>>>>>> known to be as slow as molasses when they do not call highly-
>>>>>> efficient compiled code. Any improvement (such as the link above)
>>>>>> is welcome there.
>>>>>>
>>>>>> A concept followed by languages like the one used by Julia, which
>>>>>> uses JIT compilation much more aggressively, seems to be a better
>>>>>> approach. I have barely glanced at it yet, but it certainly seems
>>>>>> worth looking into for scientific work.
>>>>>>
>>>>> This is what I'm really arguing for: If any real interpreter is doomed
>>>>> to always be much, much slower than inline binary code, then we need
>>>>> better ways to (at runtime?) convert the former into the latter, i.e.
>>>>> JIT optimization of the parts that need it.
>>>> <
>>>> {{
>>>> A real interpreter is going to average DIV 1000
>>>> Jitting instructions into a trace is going to average DIV 100.
>>>> A JIT trace is going to average DIV 10
>>>> }} per interpreted instruction.
>>>> But here JIT means converting simulated instructions into native
>>>> instructions with a touch of peepholeing.
>>> This seems a little pessimistic.
>>>
>>> My own past stats were:
>>> Naive bytecode: ~ 300..1000, depending on the design of the bytecode.
>>> Dynamic types are slower than static types;
>>> Stack vs 3R is another factor of 2.
>> <
>> Simple RISC instruction interpretation is on the order of 100
>> instructions
>> per instruction interpretation. Memory references where you have to
>> update
>> caches and TLBs are the ones making the average high. Branches are
>> also expensive if you are keeping ICache and ITLB up to date.
>
> It sounds like your numbers are for a CPU emulator, not just an
> interpreter of the running code?
>

Yeah. Or, in this case, seemingly an emulator which decodes instructions
inline rather than decoding them in advance and keeping them in a
trace-cache or similar...

My fastest "plain interpreters" got to around 10x slower than native,
but as can be noted, these were using a three-address representation and
decoding into a trace-cache; and ran directly in the host address space
rather than in an emulated memory map.

Emulating the memory map (and modeling the cache) being one of the major
costs of an emulator.

If going for speed rather than trying to keep track of clock cycles, one
useful speedup is to keep a sort of small TLB of "already translated"
addresses (which point to the "backing memory" for the page).

So, say, something like:
u64 MemGetQWord(VM_CTX *ctx, vm_addr addr)
{
char *p;
int ix, ix2;

ix=(addr>>12)&63; ix2=((addr+7)>>12)&63;
if((ctx->utlb_addr_rd[ix]==(addr&VM_ADDR_PAGE_MASK)) && (ix==ix2))
{
p=ctx->utlb_ptr_rd[ix];
return(*(u64 *)(p+(addr&4095)));
}
... Handle memory access as normal ...
}

This can in-turn sidestep much of the usual cost of the address
translation and memory-span-lookup steps (and can also deal with
emulating paged virtual memory and similar).

Though, some emulators had apparently gained some speed by leveraging
things like "nested page tables" and similar to run the emulated target
inside of a memory map managed by the underlying CPU (also presumably
running a JIT as well).

> Terje
>
>>>
>> <snip>
>>> Well, and also it would be nice if the operator precedence hierarchy
>>> were "less stupid".
>>>
>>> Like, if it were up to me, say:
>>> * / %
>>> + -
>>> & | ^
>>> << >>
>>> == != ...
>>> && ||
>>> = += -= ...
>> <
>> One does not have to deal with operator precedence when interpreting
>> non-native ISA (all that crap has been taken care of already.)
>>>
>>
>
>

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> Thomas Koenig wrote:
>> Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
>>
>> [...]
>>
>>> in the case of having non-saved registers
>>> that you'd like to use across function calls, I would probably consider
>>> writing wrappers for those function calls: The wrapper would do the
>>> save, call the actual function, then restore and return.
>>
>> The discussion on gcc has turned up an interesting option that I had
>> overlooked:
>>
>> '-fipa-ra'
>> Use caller save registers for allocation if those registers are not
>> used by any called function. In that case it is not necessary to
>> save and restore them around calls. This is only possible if
>> called functions are part of same compilation unit as current
>> function and they are compiled before it.
>>
>> Enabled at levels '-O2', '-O3', '-Os', however the option is
>> disabled if generated code will be instrumented for profiling
>> ('-p', or '-pg') or if callee's register usage cannot be known
>> exactly (this happens on targets that do not expose prologues and
>> epilogues in RTL).
>>
>> This should also be enabled with LTO.
>
> So this is basically the compiler people doing automatically the same
> kind of register optimizations that I do manually in my asm. Nice!

Yes, but only if the called function is visible.

If you link code from separate object files, or use shared libraries,
this is currently not possible.

At least for the first case, it would be interesting to record the
registers that are actually used in the object file, and use that
for later optimization.

On Tuesday, August 1, 2023 at 2:47:52 PM UTC-5, Thomas Koenig wrote:
> Terje Mathisen <terje.m...@tmsw.no> schrieb:
> > Thomas Koenig wrote:
> >> Terje Mathisen <terje.m...@tmsw.no> schrieb:
> >>
> >> [...]
> >>
> >>> in the case of having non-saved registers
> >>> that you'd like to use across function calls, I would probably consider
> >>> writing wrappers for those function calls: The wrapper would do the
> >>> save, call the actual function, then restore and return.
> >>
> >> The discussion on gcc has turned up an interesting option that I had
> >> overlooked:
> >>
> >> '-fipa-ra'
> >> Use caller save registers for allocation if those registers are not
> >> used by any called function. In that case it is not necessary to
> >> save and restore them around calls. This is only possible if
> >> called functions are part of same compilation unit as current
> >> function and they are compiled before it.
> >>
> >> Enabled at levels '-O2', '-O3', '-Os', however the option is
> >> disabled if generated code will be instrumented for profiling
> >> ('-p', or '-pg') or if callee's register usage cannot be known
> >> exactly (this happens on targets that do not expose prologues and
> >> epilogues in RTL).
> >>
> >> This should also be enabled with LTO.
> >
> > So this is basically the compiler people doing automatically the same
> > kind of register optimizations that I do manually in my asm. Nice!
> Yes, but only if the called function is visible.
>
> If you link code from separate object files, or use shared libraries,
> this is currently not possible.
<
I thought Ivan (i.e., Mill) was doing this.
>
> At least for the first case, it would be interesting to record the
> registers that are actually used in the object file, and use that
> for later optimization.

On 2023-08-01 22:54, MitchAlsup wrote:
> On Tuesday, August 1, 2023 at 2:47:52 PM UTC-5, Thomas Koenig wrote:
>> Terje Mathisen <terje.m...@tmsw.no> schrieb:
>>> Thomas Koenig wrote:
>>>> Terje Mathisen <terje.m...@tmsw.no> schrieb:
>>>>
>>>> [...]
>>>>
>>>>> in the case of having non-saved registers
>>>>> that you'd like to use across function calls, I would probably consider
>>>>> writing wrappers for those function calls: The wrapper would do the
>>>>> save, call the actual function, then restore and return.
>>>>
>>>> The discussion on gcc has turned up an interesting option that I had
>>>> overlooked:
>>>>
>>>> '-fipa-ra'
>>>> Use caller save registers for allocation if those registers are not
>>>> used by any called function. In that case it is not necessary to
>>>> save and restore them around calls. This is only possible if
>>>> called functions are part of same compilation unit as current
>>>> function and they are compiled before it.
>>>>
>>>> Enabled at levels '-O2', '-O3', '-Os', however the option is
>>>> disabled if generated code will be instrumented for profiling
>>>> ('-p', or '-pg') or if callee's register usage cannot be known
>>>> exactly (this happens on targets that do not expose prologues and
>>>> epilogues in RTL).
>>>>
>>>> This should also be enabled with LTO.
>>>
>>> So this is basically the compiler people doing automatically the same
>>> kind of register optimizations that I do manually in my asm. Nice!
>> Yes, but only if the called function is visible.
>>
>> If you link code from separate object files, or use shared libraries,
>> this is currently not possible.
> <
> I thought Ivan (i.e., Mill) was doing this.

I don't think that is quite the case. The Mill has no general working
registers; they are replaced by the "belt", a kind of finite stack onto
which all operations push their results. Any element of the belt can be
used as an input operand for other operations. The belt is never popped.
When a new result is pushed onto a full belt, the oldest result in the
belt falls off the other end and is lost.

When a call occurs, whether within the same object file or across object
files, the callee gets a new instance of the belt for its use, empty
except for the passed parameters at the front of the belt. The caller's
belt is saved and is invisible to the callee. When the call returns, the
caller sees its belt as it was before the call, except that the values
returned by the callee have been pushed onto it. The callee's belt
vanishes.

So there is no question of callee-saved vs caller-saved registers, or of
which registers are used by a function. The saving/restoring of the belt
is a HW function and is expected to run in parallel with the normal
computations.

On Tuesday, August 1, 2023 at 3:33:48 PM UTC-5, Niklas Holsti wrote:
> On 2023-08-01 22:54, MitchAlsup wrote:
> > On Tuesday, August 1, 2023 at 2:47:52 PM UTC-5, Thomas Koenig wrote:
> >> Terje Mathisen <terje.m...@tmsw.no> schrieb:
> >>> Thomas Koenig wrote:
> >>>> Terje Mathisen <terje.m...@tmsw.no> schrieb:
> >>>>
> >>>> [...]
> >>>>
> >>>>> in the case of having non-saved registers
> >>>>> that you'd like to use across function calls, I would probably consider
> >>>>> writing wrappers for those function calls: The wrapper would do the
> >>>>> save, call the actual function, then restore and return.
> >>>>
> >>>> The discussion on gcc has turned up an interesting option that I had
> >>>> overlooked:
> >>>>
> >>>> '-fipa-ra'
> >>>> Use caller save registers for allocation if those registers are not
> >>>> used by any called function. In that case it is not necessary to
> >>>> save and restore them around calls. This is only possible if
> >>>> called functions are part of same compilation unit as current
> >>>> function and they are compiled before it.
> >>>>
> >>>> Enabled at levels '-O2', '-O3', '-Os', however the option is
> >>>> disabled if generated code will be instrumented for profiling
> >>>> ('-p', or '-pg') or if callee's register usage cannot be known
> >>>> exactly (this happens on targets that do not expose prologues and
> >>>> epilogues in RTL).
> >>>>
> >>>> This should also be enabled with LTO.
> >>>
> >>> So this is basically the compiler people doing automatically the same
> >>> kind of register optimizations that I do manually in my asm. Nice!
> >> Yes, but only if the called function is visible.
> >>
> >> If you link code from separate object files, or use shared libraries,
> >> this is currently not possible.
> > <
> > I thought Ivan (i.e., Mill) was doing this.
> I don't think that is quite the case. The Mill has no general working
> registers; they are replaced by the "belt", a kind of finite stack onto
> which all operations push their results. Any element of the belt can be
> used as an input operand for other operations. The belt is never popped.
> When a new result is pushed onto a full belt, the oldest result in the
> belt falls off the other end and is lost.
<
{I know well that Mill does not have a general register model and HW based ABI.}
<
I though MILL was doing code generation and final optimizations at
link time (specialization) even when the function was not visible.
>
> When a call occurs, whether within the same object file or across object
> files, the callee gets a new instance of the belt for its use, empty
> except for the passed parameters at the front of the belt. The caller's
> belt is saved and is invisible to the callee. When the call returns, the
> caller sees its belt as it was before the call, except that the values
> returned by the callee have been pushed onto it. The callee's belt
> vanishes.
<
It is the LTO I was talking about, not the belt/register distinction.
>
> So there is no question of callee-saved vs caller-saved registers, or of
> which registers are used by a function. The saving/restoring of the belt
> is a HW function and is expected to run in parallel with the normal
> computations.

On 7/30/2023 2:49 PM, Thomas Koenig wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>
>> Every performance improvement project for an interpreter
>> (e.g. <https://lwn.net/Articles/930705/>) shows that the performance
>> of the interpreter matters. The fact that people perform performance
>> measurements shows this, too.
>
> Widely-used interpeted languages such as Python or Matlab are
> known to be as slow as molasses when they do not call highly-
> efficient compiled code. Any improvement (such as the link above)
> is welcome there.
>
> A concept followed by languages like the one used by Julia, which
> uses JIT compilation much more aggressively, seems to be a better
> approach. I have barely glanced at it yet, but it certainly seems
> worth looking into for scientific work.

I too have been intrigued by Julia. It seems to have a lot going for
it. I have been following it a little, intermittently. There have been
complaints from early on about performance, especially the start up
time. The Julia team has done a lot to improve this. See

https://julialang.org/blog/2023/04/julia-1.9-highlights/

I think they still have work to do, but it is an area of active development.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>I too have been intrigued by Julia. It seems to have a lot going for
>it. I have been following it a little, intermittently. There have been
>complaints from early on about performance, especially the start up
>time. The Julia team has done a lot to improve this. See
>
>https://julialang.org/blog/2023/04/julia-1.9-highlights/

And yet the data there show a time-to-load (TTL) of up to 13.5s for
the benchmarks. It's not explained what TTL is but I think that this
is the startup overhead on repeated startup (while the additional
overhead on first execution is TTFX). I had expected TTL to be much
lower.

This kind of startup overhead is unacceptable for many other
interactive languages. And for batch-compiled languages the startup
overhead is also usually small (at least as far as the language can
influence it). I expect that Julia is not used for executing short
scripts, but instead for long interactive sessions with few loadings
or reloadings of programs, and with relatively long computations.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On 2023-08-01 23:57, MitchAlsup wrote:
> On Tuesday, August 1, 2023 at 3:33:48 PM UTC-5, Niklas Holsti wrote:
>> On 2023-08-01 22:54, MitchAlsup wrote:
>>> On Tuesday, August 1, 2023 at 2:47:52 PM UTC-5, Thomas Koenig wrote:
>>>> Terje Mathisen <terje.m...@tmsw.no> schrieb:
>>>>> Thomas Koenig wrote:
>>>>>> Terje Mathisen <terje.m...@tmsw.no> schrieb:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> in the case of having non-saved registers
>>>>>>> that you'd like to use across function calls, I would probably consider
>>>>>>> writing wrappers for those function calls: The wrapper would do the
>>>>>>> save, call the actual function, then restore and return.
>>>>>>
>>>>>> The discussion on gcc has turned up an interesting option that I had
>>>>>> overlooked:
>>>>>>
>>>>>> '-fipa-ra'
>>>>>> Use caller save registers for allocation if those registers are not
>>>>>> used by any called function. In that case it is not necessary to
>>>>>> save and restore them around calls. This is only possible if
>>>>>> called functions are part of same compilation unit as current
>>>>>> function and they are compiled before it.
>>>>>>
>>>>>> Enabled at levels '-O2', '-O3', '-Os', however the option is
>>>>>> disabled if generated code will be instrumented for profiling
>>>>>> ('-p', or '-pg') or if callee's register usage cannot be known
>>>>>> exactly (this happens on targets that do not expose prologues and
>>>>>> epilogues in RTL).
>>>>>>
>>>>>> This should also be enabled with LTO.
>>>>>
>>>>> So this is basically the compiler people doing automatically the same
>>>>> kind of register optimizations that I do manually in my asm. Nice!
>>>> Yes, but only if the called function is visible.
>>>>
>>>> If you link code from separate object files, or use shared libraries,
>>>> this is currently not possible.
>>> <
>>> I thought Ivan (i.e., Mill) was doing this.
>> I don't think that is quite the case. The Mill has no general working
>> registers; they are replaced by the "belt", a kind of finite stack onto
>> which all operations push their results. Any element of the belt can be
>> used as an input operand for other operations. The belt is never popped.
>> When a new result is pushed onto a full belt, the oldest result in the
>> belt falls off the other end and is lost.
> <
> {I know well that Mill does not have a general register model and HW based ABI.}

{Apologies .. I should have known that, but I misunderstood your point,
as you saw.}

> <
> I though MILL was doing code generation and final optimizations at
> link time (specialization) even when the function was not visible.

The specialization stage is basically a translation from the "generic"
Mill machine code to the machine code for a particular Mill model. I
believe that the "optimization" at this stage is mainly the packing of
operations into bundles for multi-issue, which depends crucially on the
length of the belt and the set of Function Units available in the target
model.

AIUI, "specialization time" is not necessarily the same as "link time",
for the Mill. I think it will be possible to link generic-code modules
into a generic-code program, which is later (say, when the program is
installed on a machine) specialized as a whole with no further (static)
linking necessary.

>> When a call occurs, whether within the same object file or across object
>> files, the callee gets a new instance of the belt for its use, empty
>> except for the passed parameters at the front of the belt. The caller's
>> belt is saved and is invisible to the callee. When the call returns, the
>> caller sees its belt as it was before the call, except that the values
>> returned by the callee have been pushed onto it. The callee's belt
>> vanishes.
> <
> It is the LTO I was talking about, not the belt/register distinction.

Even so, the way the calls use the belt means that there is no question
of optimizing the saving and passing of registers across calls, even in
LTO. The most LTO can do is to inline the callee even for cross-module
calls.

On 8/2/2023 12:07 AM, Anton Ertl wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>> I too have been intrigued by Julia. It seems to have a lot going for
>> it. I have been following it a little, intermittently. There have been
>> complaints from early on about performance, especially the start up
>> time. The Julia team has done a lot to improve this. See
>>
>> https://julialang.org/blog/2023/04/julia-1.9-highlights/
>
> And yet the data there show a time-to-load (TTL) of up to 13.5s for
> the benchmarks. It's not explained what TTL is but I think that this
> is the startup overhead on repeated startup (while the additional
> overhead on first execution is TTFX). I had expected TTL to be much
> lower.
>
> This kind of startup overhead is unacceptable for many other
> interactive languages. And for batch-compiled languages the startup
> overhead is also usually small (at least as far as the language can
> influence it). I expect that Julia is not used for executing short
> scripts, but instead for long interactive sessions with few loadings
> or reloadings of programs, and with relatively long computations.

As you can see from the sentence you didn't copy from my post, I agree
with you, and furthermore, I think the developers do too. Also, I
expect from its primary use as a "scientific oriented" language, that
your expectations of its usage patterns are correct, but I am not expert
in the field.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 8/2/2023 2:10 AM, Niklas Holsti wrote:
> On 2023-08-01 23:57, MitchAlsup wrote:

snip

>> I though MILL was doing code generation and final optimizations at
>> link time (specialization) even when the function was not visible.
>
>
> The specialization stage is basically a translation from the "generic"
> Mill machine code to the machine code for a particular Mill model. I
> believe that the "optimization" at this stage is mainly the packing of
> operations into bundles for multi-issue, which depends crucially on the
> length of the belt and the set of Function Units available in the target
> model.
>
> AIUI, "specialization time" is not necessarily the same as "link time",
> for the Mill.

Right.

> I think it will be possible to link generic-code modules
> into a generic-code program, which is later (say, when the program is
> installed on a machine) specialized as a whole with no further (static)
> linking necessary.

That implies that link time occurs prior to specialization time. I
don't know, but ISTM that would increase specialization time, as you
would have to "repspecialize" the "library modules" each time you made a
change to the source and had to recompile and thus relink the program.
Doing the specialization before the link would eliminate that.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 2023-08-02 17:28, Stephen Fuld wrote:
> On 8/2/2023 2:10 AM, Niklas Holsti wrote:
>> On 2023-08-01 23:57, MitchAlsup wrote:
>
> snip
>
>>> I though MILL was doing code generation and final optimizations at
>>> link time (specialization) even when the function was not visible.
>>
>>
>> The specialization stage is basically a translation from the "generic"
>> Mill machine code to the machine code for a particular Mill model. I
>> believe that the "optimization" at this stage is mainly the packing of
>> operations into bundles for multi-issue, which depends crucially on
>> the length of the belt and the set of Function Units available in the
>> target model.
>>
>> AIUI, "specialization time" is not necessarily the same as "link
>> time", for the Mill.
>
> Right.
>
>
>> I think it will be possible to link generic-code modules into a
>> generic-code program, which is later (say, when the program is
>> installed on a machine) specialized as a whole with no further
>> (static) linking necessary.
>
> That implies that link time occurs prior to specialization time.

I did not mean that this would always be the order, only that it would
be a possible order.

> I don't know, but ISTM that would increase specialization time, as
> you would have to "repspecialize" the "library modules" each time you
> made a change to the source and had to recompile and thus relink the
> program. Doing the specialization before the link would eliminate
> that.

Yes, and I think it will also be possible do it in that order, perhaps
during program development when there is no need to generate a portable
generic-code version of the program.

On 8/2/2023 7:28 AM, Stephen Fuld wrote:
> On 8/2/2023 2:10 AM, Niklas Holsti wrote:
>> On 2023-08-01 23:57, MitchAlsup wrote:
>
> snip
>
>>> I though MILL was doing code generation and final optimizations at
>>> link time (specialization) even when the function was not visible.
>>
>>
>> The specialization stage is basically a translation from the "generic"
>> Mill machine code to the machine code for a particular Mill model. I
>> believe that the "optimization" at this stage is mainly the packing of
>> operations into bundles for multi-issue, which depends crucially on
>> the length of the belt and the set of Function Units available in the
>> target model.
>>
>> AIUI, "specialization time" is not necessarily the same as "link
>> time", for the Mill.
>
> Right.
>
>
>> I think it will be possible to link generic-code modules into a
>> generic-code program, which is later (say, when the program is
>> installed on a machine) specialized as a whole with no further
>> (static) linking necessary.
>
> That implies that link time occurs prior to specialization time.  I
> don't know, but ISTM that would increase specialization time, as you
> would have to "repspecialize" the "library modules" each time you made a
> change to the source and had to recompile and thus relink the program.
> Doing the specialization before the link would eliminate that.

Linking before specialization has the same advantages and costs as any
other LTO: you have to regenerate the machine code from the optimized
program as linked. You can link after specialization too, or mix with
some modules prelinked and some postlinked.

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>I too have been intrigued by Julia. It seems to have a lot going for
>>it. I have been following it a little, intermittently. There have been
>>complaints from early on about performance, especially the start up
>>time. The Julia team has done a lot to improve this. See
>>
>>https://julialang.org/blog/2023/04/julia-1.9-highlights/
>
> And yet the data there show a time-to-load (TTL) of up to 13.5s for
> the benchmarks. It's not explained what TTL is but I think that this
> is the startup overhead on repeated startup (while the additional
> overhead on first execution is TTFX). I had expected TTL to be much
> lower.

The Julia core is slow to start up, but not that slow:

$ echo "" | time ./julia
0.24user 0.27system 0:00.15elapsed 338%CPU (0avgtext+0avgdata 230452maxresident)k
0inputs+0outputs (0major+29689minor)pagefaults 0swaps

(where this is actually from "spinning rust", as Tejre is wont to say).

The long loading times are for packages, where they have now
improved the precompilation.

> This kind of startup overhead is unacceptable for many other
> interactive languages.

People don't use Julia for extracting the first column of a text file,
it is possible to use awk or cut or perl or Python for that.

Where it shines is its performance for mathematical tasks.
Take solving ordinary differential equations. In Python, the
expression for the right-hand side has to be interpreted, which
makes it slooooow. Julia compiles it JIT and gets performance
which is fairly close to the ones by a compiled language.

And the advantage of using an interpteter, rather than a library in
a compiled language, is ease of use - no need to worry about
overlong argument lists.

In a way, this is funny. Pre-Fortran 90 scientific packages
suffer from overlong argument lists, mostly for array bounds and
work space. Fortran 90, influenced by Matlab, introduced ways to
do away with that, but when it was gaining traction, many people
had already moved to C, which suffers from the same shortcomings
as FORTRAN <= 77, plus some more.

I've worked with Sundials, and I have certainly wished for a version
with fewer possibilities for bugs...

>And for batch-compiled languages the startup
> overhead is also usually small (at least as far as the language can
> influence it). I expect that Julia is not used for executing short
> scripts, but instead for long interactive sessions with few loadings
> or reloadings of programs, and with relatively long computations.

Or in batch.

On Sun, 30 Jul 2023, Anton Ertl wrote:

> Apart from saving the F0 prefix, what alternative uses could that bit have
> been used for?

If the bit is set, then you get another prefix byte. That would allow
three-address instructions more compactly than with the current scheme. But
probably not so nice for the decoders.

On Saturday, August 12, 2023 at 5:26:36 PM UTC-5, Elijah Stone wrote:
> On Sun, 30 Jul 2023, Anton Ertl wrote:
>
> > Apart from saving the F0 prefix, what alternative uses could that bit have
> > been used for?
>
> If the bit is set, then you get another prefix byte. That would allow
> three-address instructions more compactly than with the current scheme. But
> probably not so nice for the decoders.
<
With 15,000 instructions, decoders are already stupidly complicated.
What is another prefix going to add to it ?? A:: not much.

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Saturday, August 12, 2023 at 5:26:36 PM UTC-5, Elijah Stone wrote:
>> On Sun, 30 Jul 2023, Anton Ertl wrote:
>>
>> > Apart from saving the F0 prefix, what alternative uses could that bit have
>> > been used for?
>>
>> If the bit is set, then you get another prefix byte. That would allow
>> three-address instructions more compactly than with the current scheme. But
>> probably not so nice for the decoders.
><
> With 15,000 instructions, decoders are already stupidly complicated.
> What is another prefix going to add to it ?? A:: not much.

I recently read that Intel decoders have formed a union and gone on
strike, demanding better working conditions.

In article <u9r0jd$1ftnb$1@dont-email.me>,
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
>Thomas Koenig wrote:
>> One problem I see is that all the new registers are caller-saved,
>> for compatibility with existing ABIs. This is needed due to stack
>> unwinding and setjmp/longjmp, but restricts their benefit due to
>> having to spill them across function calls. It might be possible
>> to set __attribute__((nothrow)) on functions where this cannot
>> happen, and change some caller-saved to callee-saved registers
>> in that case, but that could be an interesting discussion.
>
>I'm not worried at all about this point: The only places where I really
>want lots of registers are in big/complicated leaf functions!
>
>If a function both needs lots of registers _and_ have to call any
>non-inlined functions, then it really isn't that time critical.

Defensively written code which calls error handlers offline mean most
leaf calls are not really leafs. Also, small leaf functions are pulled
into the calling function through inlining, and the resulting function
is no longer a leaf.

Code other than small toys often have critical loops that are not in
leaf functions. If you spend your time looking at programs of less than
500 lines, then you will miss what larger programs are doing. Designing
for benchmarks is a bad idea.

A large program I work on is helped by the GCC ability to "borrow"
scratch registers if it can peek into the functions being called and see
that the registers won't be used, and so use scratch registers knowing
the called routine won't overwrite them. This doesn't always work since
the called functions are often in other files, defeating the GCC
optimization. I don't do LTO since although performance is important,
build time and debuggability is also important, and you have to draw the
line somewhere. I've dumped out a disassembly when this program is
compiled for Aarch64, and I see no use of x14-x18 (the highest numbered
scratch registers) EXCEPT when GCC has realized it can borrow them from
a leaf routine which isn't using them. Meanwhile, loops are forced to
spill values to the stack since they don't fit in registers. This is
not just a performance issue, it's a code bloat issue.

The mere existence of the GCC feature to do this scratch register
borrowing shows it is useful.

And again, if you need 16 more registers in your leaf function, then you
definitely have time to spill/fill them, since whatever you are doing is
taking a lot more time than the spill/fill. And the argument is simple:
it's trivial for large leaf routines to spill/fill registers at almost
no performance cost, but there really is no great solution for a
performance critical non-leaf routine to get more registers. Therefore,
ABIs should provide more preserved registers and fewer scratch
registers.

It is a mistake to make these new registers caller save. There are ways
to make them callee save. However, I will admit due to the way x86_64
CPUs optimize loads, the cost to it of spill/fill of registers onto the
stack in a non-leaf routine is not as bad as on a RISC. It's how it
gets away with not having enough registers now.

Kent

On Thursday, August 17, 2023 at 1:06:02 PM UTC-5, Kent Dickey wrote:
> In article <u9r0jd$1ftnb$1...@dont-email.me>,
> Terje Mathisen <terje.m...@tmsw.no> wrote:
> >Thomas Koenig wrote:
> >> One problem I see is that all the new registers are caller-saved,
> >> for compatibility with existing ABIs. This is needed due to stack
> >> unwinding and setjmp/longjmp, but restricts their benefit due to
> >> having to spill them across function calls. It might be possible
> >> to set __attribute__((nothrow)) on functions where this cannot
> >> happen, and change some caller-saved to callee-saved registers
> >> in that case, but that could be an interesting discussion.
> >
> >I'm not worried at all about this point: The only places where I really
> >want lots of registers are in big/complicated leaf functions!
> >
> >If a function both needs lots of registers _and_ have to call any
> >non-inlined functions, then it really isn't that time critical.
>
> Defensively written code which calls error handlers offline mean most
> leaf calls are not really leafs.
<
This seems to be poor programming style--because the error checking
can be returned to the caller converting::
<
leaf_subroutine()
<
leaf_subroutine()
{ .
.
if( some condition ) exception( 37 );
<
converts into::
<
if( except = leaf_now_function() ) exception( excpt );
<
leaf_now_function()
{ .
.
if( some condition ) return 37;
<
> Also, small leaf functions are pulled
> into the calling function through inlining, and the resulting function
> is no longer a leaf.
<
Don't you mean that when a non-leaf subroutine inlines all of its
called subroutines it becomes a leaf ??
<

On Thursday, August 17, 2023 at 3:20:38 PM UTC-6, MitchAlsup wrote:
> On Thursday, August 17, 2023 at 1:06:02 PM UTC-5, Kent Dickey wrote:

> > Also, small leaf functions are pulled
> > into the calling function through inlining, and the resulting function
> > is no longer a leaf.
> <
> Don't you mean that when a non-leaf subroutine inlines all of its
> called subroutines it becomes a leaf ??

That is _also_ true, but that doesn't make what he wrote wrong.

He was saying that if a non-leaf subroutine inlines _one_ of its
called subroutines, which _was_ a leaf, then, unless that was its
last called subroutine, the caller remains a non-leaf routine, and
so the code moved inline is no longer part of a leaf.

That, too, is entirely true.

John Savard

Quadibloc wrote:
> On Thursday, August 17, 2023 at 3:20:38 PM UTC-6, MitchAlsup wrote:
>> On Thursday, August 17, 2023 at 1:06:02 PM UTC-5, Kent Dickey wrote:
>
>>> Also, small leaf functions are pulled
>>> into the calling function through inlining, and the resulting function
>>> is no longer a leaf.
>> <
>> Don't you mean that when a non-leaf subroutine inlines all of its
>> called subroutines it becomes a leaf ??
>
> That is _also_ true, but that doesn't make what he wrote wrong.
>
> He was saying that if a non-leaf subroutine inlines _one_ of its
> called subroutines, which _was_ a leaf, then, unless that was its
> last called subroutine, the caller remains a non-leaf routine, and
> so the code moved inline is no longer part of a leaf.
>
> That, too, is entirely true.

To me as an asm programmer, this indicates the need to partition (if
possible) non-leaf functions so that major parts can use all registers,
with the required push/pop blocks around them. It is only when you have
to call something inside the innermost loops that you really get into
trouble.

Probably the most common pattern for calling functions inside inner
loops is like Mitch mentioned, i.e. for error handling/exceptions, and
these are by definition not speed critical, so they can easily afford
extra caller save/restore blocks around them, right?

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"