[Mono-devel-list] [Patch] Manged code is fast!
Ben Maurer
05mauben at hawken.edu
Fri May 21 07:54:03 EDT 2004
The *first* char of the string is always dword aligned, but the second one isnt :-).
We should be optimizing the x [c] construct for pointer x. Right now we are not even using a memindex type thing, which should make it MUCH faster.
However, I just realized that there is a better way here. You are trying to eliminate the unmanaged transition here. However, look at the code again: you have to make a transition in order to alloc the string. A better way would be to create a specific icall for this method that did the memcopy as part of the icall. You still have 1 managed/unmanaged round trip, but you get the fast memcopy.
-- Ben
>>> "Andreas Nahr" <ClassDevelopment at A-SoftTech.com> 05/21/04 03:48 AM >>>
In Text
>
> > private unsafe static void CharCopy (char* source, char* destination,
int count)
>
> What is the perf here if things are not dword aligned?
I think for me thing always were dword aligned. We should ensure that
Strings always get the right alignment in the JIT.
>
> > + while (count >= 16) {
> > + *((int*) destination) = *((int*) source);
> > + destination += 2;
> > + source += 2;
> > + *((int*) destination) = *((int*) source);
> > + destination += 2;
> > + source += 2;
>
> It is probably better to do something like:
>
> *((int*) dest + x) = ...
Did you really test this or are you just guessing?
For me the above solution (although more source code) always produced
superior speed.
However I used the notation *((int*) dest[x]) =...
But this seems to be compiled into same IL.
> To figure out why, take a look at what kind of assembly is generated.
> Probably, it is using a memindex type instruction. So the extra addition
> has no overhead, but it saves you the two add instructions.
I started this way but now do optimization using mostly microbenchmarks,
because my guesses did at most time not match reallity.
E.g. I think your guess is wrong, because then this *((int*) dest[x]) would
be faster, however it is not...
> Also, I have a patch that I am working on which does an assembly impl of
> String.Equals. I got great perf on it, so maybe we can get something
> similar.
Oh, I'm working on string for some months now and have a patch which added a
lot of speed to Equals, too. However I didn't look at it for some time and
things got shuffled around a bit with the pointer perf improvements and the
intrinsification of the char offsets in the JIT, so my figures may not be
valid anymore.
Andreas
P.S.
I just tried *((int*) dest + x) = ... to be sure and the perf was
catastrophical
More information about the Mono-devel-list
mailing list