[m-dev.] 32-bit sources on 64-bit target

[Julien Fischer]

On Tue, Mar 12, 2013 at 11:02 AM, Peter Wang <novalazy at gmail.com> wrote:
> On Fri, 8 Mar 2013 16:47:00 +1100, Julien Fischer <jfischer at opturion.com> wrote:
>> On Fri, Mar 8, 2013 at 3:58 PM, Peter Wang <novalazy at gmail.com> wrote:
>> > On Fri, 8 Mar 2013 15:03:19 +1100, Julien Fischer <jfischer at opturion.com> wrote:
>> >> Hi Peter,
>> >>
>> >> On Fri, Mar 8, 2013 at 10:51 AM, Peter Wang <novalazy at gmail.com> wrote:
>> >> > On Fri, 8 Mar 2013 00:38:58 +1100, Julien Fischer <jfischer at opturion.com> wrote:
>> >> >> On Fri, Mar 8, 2013 at 12:17 AM, Paul Bone <paul at bone.id.au> wrote:
>> >> >> > On Thu, Mar 07, 2013 at 06:00:24PM +1100, Julien Fischer wrote:
>> >> >> >> On Thu, Mar 7, 2013 at 5:08 PM, Peter Wang <novalazy at gmail.com> wrote:
>> >> >> >> > The compiler built from pre-generated sources WILL be installed.
>> >> >> >> > For now, I can't think of why that would be a problem.
>> >> >> >>
>> >> >> >> It wouldn't be at the moment since the compiler (and other tools)
>> >> >> >> are currently built with --mercury-linkage static.  It would be a problem,
>> >> >> >> if that were not the case.
>> >> >> >>
>> >> >> >
>> >> >> > How much of a performance gain does unboxed floats and 3 tag bits represent
>> >> >> > specifically for the compiler?
>> >> >
>> >> > Suprisingly, significant: (default speedtest)
>> >> >
>> >> > mercury_compile.01 average of 6 with ignore=1     10.00
>> >> > mercury_compile.02 average of 6 with ignore=1     12.08
>> >>
>> >> That's quite a difference.  Is mercury_compile.02 built directly from
>> >> the source distribution
>> >> C files.
>> >
>> > Yes.
>>
>> And was mercury_compile.01 built with similar options, other than
>> the number of tag bits and unboxed floats.
>
> I simulated what a normal, but informed, user would do.  Unpack the
> srcdist tarball, build it once, install (mercury_compile.02).
> Unpack the tarball again, build it using the previously installed
> compiler, install again to another location (mercury_compile.01).
>
>> The options used for
>> the source diet are:
>>
>>     -O5 --opt-space --cross-compiling --no-smart-indexing
>>
>
> I repeated the benchmark after installing the srcdist64 package[*].
> Don't know why my computer was running slower last week, but the results
> are consistent:
>
> mercury_compile.01 average of 6 with ignore=1      9.19
> mercury_compile.02 average of 6 with ignore=1     11.29
> mercury_compile.03 average of 6 with ignore=1     11.32
>
> The srcdist64 compiler is .03.  It shows that the number of tag bits and
> unboxed floats make no difference to the compiler, so one of the other
> options makes the difference.  (My guess is that --cross-compiling
> disables compile-time evaluation which degrades tree_bitset, but only
> because I'm a bit familiar with that module.)

Yes, --cross-compiling does disable some compile-time evaluation, and yes,
that will cause the performance of tree_bitset to degrade.

> We might consider disabling --cross-compiling for the srcdist64 package?

I'm happy to leave it as it is, I don't think the performance
difference is that great.

> [*] For the srcdist64 package, I had to hack configure.ac to not force
> mercury_cv_low_tag_bits=2 and mercury_cv_unboxed_floats=no when building
> from generated sources.

Ah, I forgot about that ;-)   The configure script will require some
minor modifications
to support 64-bit source distributions -- I'll fix it up later this week.

Cheers,
Julien.