• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Timing puzzle (was Release Build Fails)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Timing puzzle (was Release Build Fails)


  • Subject: Re: Timing puzzle (was Release Build Fails)
  • From: "Kyle Sluder" <email@hidden>
  • Date: Wed, 10 Oct 2007 14:53:36 +0100

My first guess is that the function isn't getting inlined correctly.
Check http://gcc.gnu.org/onlinedocs/gcc/Inline.html and try adding
-Winline to your compiler flags in Xcode.

Of course, using Shark would also be a good idea.

--Kyle Sluder

On 10/10/07, Michael McLaughlin <email@hidden> wrote:
> Release build failed because it tried to create Altivec code for i386.  That
> is now OK but a timing puzzle remains.
>
> Since the code is so short, I have appended it below.  It is modified from a
> third-party public-domain offering (SFMT).
>
> The puzzle is why (obsolete) CodeWarrior is so much faster than Xcode 2.4.1
> given that all Altivec options are in effect.  The relevant timings (in
> seconds) are as follows:
>
>             CW            Xcode
> Initted:     0              0
> Filled:     5.65           5.66
> Done:      12.09          50.87
>
> SFMT is a pseudo-random number generator (PRNG) so the slow part of this
> code *should* be the Filled step since that is where the "random" numbers
> are computed.  (At least, that was my guess.)
>
> That filling step is done in a library created in Xcode so it is not
> surprising that the timing is nearly identical.
>
> Can anyone suggest why the calling loop is so much slower?  The called
> function is simply
>
> /** generates a random number on [0,1) with 53-bit resolution*/
> inline static double to_res53(uint64_t v)
> {
>     return v * (1.0/18446744073709551616.0L);
> }
>
> Obviously, this requires a long double.  Perhaps, Xcode is doing this
> correctly and CW is faking it. Does that sound likely?
>
> ***** code *****
>
> #include <stdio.h>
> #define _XOPEN_SOURCE 600
> #include <stdlib.h>
> #include <time.h>
> #include "SFMT.h"
>
> int main(int argc, char* argv[]) {
>     clock_t clo, clo2;
>     uint64_t i, j, cnt, seed;
>     double x, y, pi;
>     const unsigned long NUM = 100000000;
>     const unsigned long R_SIZE = 2 * NUM;
>     unsigned long size;
>     uint64_t *array;
>
>     seed = 12345;
>    size = get_min_array_size64();
>     if (size < R_SIZE) {
>         size = R_SIZE;
>     }
>
>     array = malloc(sizeof(double) * size);
>     if (array == NULL) {
>         printf("can't allocate memory.\n");
>         return 1;
>     }
>
>     cnt = 0;
>     j = 0;
>
>     clo = clock();
>     init_gen_rand(seed);
>     clo2 = clock();
>     printf("Initted: %g\n", (float) (clo2 - clo)/CLOCKS_PER_SEC);
>     fill_array64(array, size);
>     clo2 = clock();
>     printf("Filled: %g\n", (float) (clo2 - clo)/CLOCKS_PER_SEC);
>     for (i = 0; i < NUM; i++) {
>         x = to_res53(array[j++]);
>         y = to_res53(array[j++]);
>         if (x * x + y * y < 1.0) {
>              cnt++;
>         }
>     }
>     clo2 = clock();
>     printf("Done: %g\n", (float) (clo2 - clo)/CLOCKS_PER_SEC);
>     free(array);
>     pi = (double)cnt / NUM * 4;
>     printf("%lf\n", pi);
>     return 0;
> }
>
> --
> Mike McLaughlin
>
>  _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list      (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >Timing puzzle (was Release Build Fails) (From: Michael McLaughlin <email@hidden>)

  • Prev by Date: Timing puzzle (was Release Build Fails)
  • Next by Date: Re: Release build fails
  • Previous by thread: Timing puzzle (was Release Build Fails)
  • Next by thread: Re: Timing puzzle (was Release Build Fails)
  • Index(es):
    • Date
    • Thread