[m-rev.] for review: optimize calls to string.format and related predicates

[Paul Bone]

On Thu, Sep 03, 2009 at 09:34:45PM +1000, Julien Fischer wrote:
>
> On Wed, 2 Sep 2009, Zoltan Somogyi wrote:
>
>> Besides a review of the change itself, I am seeking feedback on what
>> exactly the optimization should do.
>>
>> For optimizing e.g. io.format("%d_%d", [i(X), i(Y), !IO), this diff currently
>> generates
>>
>> 	V1 = int_to_string(X),
>> 	V2 = "_"
>> 	V3 = V2 ++ V1
>> 	V4 = int_to_string(Y),
>> 	V5 = V4 ++ V3
>> 	io.write_string(V5, !IO)
>>
>> Should it instead generate
>>
>> 	V1 = int_to_string(X),
>> 	io.write_string(V1, !IO),
>> 	V2 = "_"
>> 	io.write_string(V2, !IO),
>> 	V3 = int_to_string(Y),
>> 	io.write_string(V3, !IO)
>>
>> This avoids memory allocation, but it requires more overheads in the I/O
>> system, e.g. retrievals of the current output stream. What do you think?
>
> The former seems preferable in the case where X, Y or both are (become)
> known, e.g. through the predicate being inlined, since that may lead to
> some of the string concatenations being optimised away.
>
> Although, it mightn't be if we had an optimisation that merged
> consecutive calls to io.write_string/{3,4}.  Something like:
>
>    io.write_string("Hello", !IO),
>    io.write_string(" World", !IO),
>
> into
>
>    io.write_string("Hello World", !IO)
>
> Most of the time it won't matter which of the two choices are applied -  
> for those where it does I wonder whether we could use the profiling 
> feedback
> system to tell us what the better choice is.
>

If it doesn't matter then why bother using the profiler?  Do you mean where we
can't tell if it matters or not.

Regarding the (deep) profiler.  I want to add TSC support, using the
code I wrote earlier to measure the duration of things in CPU clock cycles.
It'll work on Pentium and newer x86/x86_64 chips.

IMHO this is probably portable enough since now days there are only a handful
of other common-ish architectures and they're usually used for special
purposes.  (Apple switching to Intel and Sun using Intel and Sparc spelt the
end of diversity for me, (Excluding ARM in embedded devices and Power in some
HPC situations))


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20090904/affb8c38/attachment.sig>