Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #140331

Re: Simple 2d C99 fractal plotter...

Show all headers | View raw

On 1/27/2019 7:36 AM, David Brown wrote:
> On 27/01/2019 15:13, Bart wrote:
>> On 27/01/2019 12:20, David Brown wrote:
>>> On 26/01/2019 13:35, Bart wrote:
>>
>>>> msvc: no tgmath.h (and loads of errors when you just comment it out. 
>>>> What is tgmath.h for anyway?)
>>>>
>>>
>>>
>>> Chris said it was a C99 program.
>>
>> Most of those compilers, except for bcc, are reasonably full c99 
>> compilers. Yet tgmath.h, which varies from 130 to 1400 lines where it 
>> exists, seems to be missing from dmc, tcc and msvc.
>>
> 
> As you know, a "C implementation" consists of a C compiler, headers, a 
> standard library, and whatever other bits and pieces are needed to turn 
> C code into an executable (assembler, linker, etc.).  A compiler that 
> can handle C99 syntax is only part of the system - if you don't have the 
> C99 headers, you don't have a C99 implementation.  That seems to be the 
> case for these C implementations - at least with the installation on 
> your system (maybe other tcc or dmc installations have C99 headers and 
> libraries).
> 
>>    A C implementation that does not have
>>> tgmath.h, complex.h, and the required libraries is not a C99 
>>> implementation.  So it is entirely reasonable that his program does 
>>> not work on systems that don't support C99 - the standard is only 20 
>>> years old, and not every tool has caught up yet.
>>
>> No, it's just support for tgmath.h that is not so universal. Actually 
>> I'm still not sure what it does.
>>
> 
> At the risk of stating the blindingly obvious, "tgmath.h" is a header of 
> type-generic maths macros.  It is documented in the C99 (and C11, and 
> C17) standards.  And if you don't like reading the standards documents 
> (which is not unreasonable - they are not always easy to read), this 
> site is a good reference for C and C++:
> 
> <https://en.cppreference.com/w/c/numeric/tgmath>
> 
> I can't tell you how universal support for tgmath.h is.  For my modest C 
> needs on big systems, my gcc installations support it fine.  For my 
> embedded programming, I usually write my own maths functions anyway and 
> thus have little need of <tgmath.h> or even <math.h>
> 
> 
>>>> clang: error: passing '_Complex float' to parameter of incompatible
>>>>   type '_Fcomplex' (aka 'struct _C_float_complex')
>>>>      __tg_acos(float _Complex __x) {return cacosf(__x);} etc
>>>>                                                   ^~~
>>>
>>> I wonder if that is something specific to clang on Windows using MS's 
>>> headers?  (This is purely speculation, not based on any experience of 
>>> the tool on Windows.)
>>
>> This is an odd one: clang seems to rely on msvc somehow, but msvc 
>> doesn't have tgmath,h, yet clang has.
>>
> 
> MSVC has famously bad C99 support.  clang has perfectly good C99 
> support.  But this sort of thing lies partly between the compiler and 
> the library (the two main parts of the C implementation).  <tgmath.h> 
> cannot be written in standard C (until C11) - it requires 
> compiler-specific features.  So it is one of the headers that is likely 
> to come with the compiler rather than the library.  On the other hand, 
> the /implementations/ of the functions used will be part of the C 
> run-time library.  MSVC uses highly inefficient DLL's for this, and 
> their DLL's don't have good C99 support.  So it does not surprise me 
> that the hack they have made with fitting clang onto MSVC results in the 
> <tgmath.h> header being fine while missing the functions in the library. 
>   (The same applies if you are using MingW rather than MSVC - that's why 
> I recommended MingW-64.)  I'd imagine that with enough effort, you could 
> find options or libraries to handle this, or you could install clang 
> along with fuller libraries.
> 
>>>> Interestingly, all programs seem to have the same runtime: 
>>>> optimisation makes little difference (all take around 6-7 seconds on 
>>>> my machine, of which generating the .ppm file is a tiny part).
>>>>
>>>
>>> Depending on the cpu you are running on, that is not too surprising 
>>> for a program that works with a lot of floating point calculations, 
>>> especially things like square roots and division.
>> ...
>>> Still, in my testing with gcc 5.4 (64-bit Linux), unoptimised code 
>>> took 0.68s, while with reasonable fast options "-O3 -ffast-math 
>>> -march=native" it takes 0.44 seconds.
>>
>>> Since that is an order of magnitude faster than your system, and my 
>>> PC is not usually /that/ much faster than yours, it could well be the 
>>> effect of scheduling, pipelining, and out-of-order execution on the 
>>> particular cpu.
>>
>> Actually there is something I overlooked completely, which is the 
>> printf that is called on every point. It overwrites the same line so 
>> you don't appreciate how many lines are displayed.
>>
> 
> You are right - I never noticed that (I didn't look much at the program 
> itself).  Yes, this will dominate.

Well, "almost" every point in the grand scheme of things. In the ct_ifs 
function the output is within the damn fractal computation loop.

         if (! (i % 256))
         {
             printf("rendering: %lu of %lu\r", i + 1, n);
         }

That mod is not pretty as well...

_________________
// Compute the fractal
void
ct_ifs(
     struct ct_plot* const plot,
     unsigned long n
){
     // 2 sets
     double complex jp[] = {
         .5 + 0 * I,
         -5.5 + I*.0
     };

     double complex z = 0+0*I;
     double complex c = 0+0*I;

     for (unsigned long i = 0; i < n; ++i)
     {
         double rn0 = rand() / (RAND_MAX - .0);
         double rn1 = rand() / (RAND_MAX - .0);

         if (rn0 > .5)
         {
             c = jp[0];
         }

         else
         {
             c = jp[1];
         }


         double complex d = z - c;
         double complex root = csqrt(d);

         z = root;

         if (rn1 > .5)
         {
             z = -root;
         }

          ct_plot_point(plot, z, 255);
          ct_plot_point(plot, root, 255);


   //****** Output in 256 chunks.
         if (! (i % 256))
         {
             printf("rendering: %lu of %lu\r", i + 1, n);
         }
     }

     printf("rendering: %lu of %lu\n", n, n);
}
_________________

Removing this "pointless, in a sense... progress" output will greatly 
increase the speed of the fractal calculations. I just left it in there 
so I could see the damn progress. I should use a fflush(stdout) after 
each call to printf to make it even more inefficient. ;^)


Sorry about that.

> 
>> Without that, then it was much faster (certainly on Windows). Fast 
>> enough that generating the .ppm was was significant.
>>
>> So without the ppm, and without printf, timings varied from 0.75 
>> seconds to 1.2 seconds, with gcc-O3 fastest.
>>
>> Using your additional options, gcc took 0.5 seconds. Just over twice 
>> as fast as my unoptimised bcc (1.1) or gcc-O0 (1.15); this is where 
>> the floating point overheads limit the difference.
>>
> 
> Interesting.
> 
> 
> 

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Simple 2d C99 fractal plotter... "Chris M. Thomasson" <ahh_f_it@crap.nothing> - 2019-01-25 14:24 -0800
  Re: Simple 2d C99 fractal plotter... "Chris M. Thomasson " <ahh_f_it@crap.nothing> - 2019-01-25 15:11 -0800
  Re: Simple 2d C99 fractal plotter... Eli the Bearded <*@eli.users.panix.com> - 2019-01-25 23:50 +0000
    Re: Simple 2d C99 fractal plotter... "Chris M. Thomasson" <ahh_f_it@crap.nothing> - 2019-01-25 16:33 -0800
    Re: Simple 2d C99 fractal plotter... Bart <bc@freeuk.com> - 2019-01-26 00:45 +0000
      Re: Simple 2d C99 fractal plotter... "Chris M. Thomasson " <ahh_f_it@crap.nothing> - 2019-01-25 16:55 -0800
        Re: Simple 2d C99 fractal plotter... Bart <bc@freeuk.com> - 2019-01-26 00:59 +0000
      Re: Simple 2d C99 fractal plotter... Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-01-26 20:29 +0000
        Re: Simple 2d C99 fractal plotter... Bart <bc@freeuk.com> - 2019-01-26 21:37 +0000
          Re: Simple 2d C99 fractal plotter... Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-01-27 12:11 +0000
            Re: Simple 2d C99 fractal plotter... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-27 13:40 +0000
  Re: Simple 2d C99 fractal plotter... Bart <bc@freeuk.com> - 2019-01-26 00:57 +0000
    Re: Simple 2d C99 fractal plotter... "Chris M. Thomasson" <ahh_f_it@crap.nothing> - 2019-01-27 15:37 -0800
  Re: Simple 2d C99 fractal plotter... Bart <bc@freeuk.com> - 2019-01-26 12:35 +0000
    Re: Simple 2d C99 fractal plotter... David Brown <david.brown@hesbynett.no> - 2019-01-27 13:20 +0100
      Re: Simple 2d C99 fractal plotter... Bart <bc@freeuk.com> - 2019-01-27 14:13 +0000
        Re: Simple 2d C99 fractal plotter... David Brown <david.brown@hesbynett.no> - 2019-01-27 16:36 +0100
          Re: Simple 2d C99 fractal plotter... "Chris M. Thomasson" <ahh_f_it@crap.nothing> - 2019-01-27 14:28 -0800
            Re: Simple 2d C99 fractal plotter... Bart <bc@freeuk.com> - 2019-01-27 23:53 +0000
          Re: Simple 2d C99 fractal plotter... "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-01-29 13:11 -0800
            Re: Simple 2d C99 fractal plotter... Bart <bc@freeuk.com> - 2019-01-29 22:23 +0000
              Re: Simple 2d C99 fractal plotter... "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-02-04 15:30 -0800
                Re: Simple 2d C99 fractal plotter... Bart <bc@freeuk.com> - 2019-02-05 01:26 +0000
                Re: Simple 2d C99 fractal plotter... Ian Collins <ian-news@hotmail.com> - 2019-02-05 16:14 +1300
                Re: Simple 2d C99 fractal plotter... David Brown <david.brown@hesbynett.no> - 2019-02-05 11:38 +0100
                Re: Simple 2d C99 fractal plotter... Bart <bc@freeuk.com> - 2019-02-05 11:14 +0000
                Re: Simple 2d C99 fractal plotter... David Brown <david.brown@hesbynett.no> - 2019-02-05 14:35 +0100
                Re: Simple 2d C99 fractal plotter... Bart <bc@freeuk.com> - 2019-02-05 15:06 +0000
                Re: Simple 2d C99 fractal plotter... David Brown <david.brown@hesbynett.no> - 2019-02-05 17:02 +0100
                Re: Simple 2d C99 fractal plotter... Bart <bc@freeuk.com> - 2019-02-05 19:07 +0000
                Re: Simple 2d C99 fractal plotter... Ian Collins <ian-news@hotmail.com> - 2019-02-06 08:12 +1300
                Re: Simple 2d C99 fractal plotter... Keith Thompson <kst-u@mib.org> - 2019-02-05 12:49 -0800
                Re: Simple 2d C99 fractal plotter... David Brown <david.brown@hesbynett.no> - 2019-02-05 22:39 +0100
        Re: Simple 2d C99 fractal plotter... Keith Thompson <kst-u@mib.org> - 2019-01-27 13:09 -0800
  Re: Simple 2d C99 fractal plotter... Bart <bc@freeuk.com> - 2019-01-26 18:53 +0000
    Re: Simple 2d C99 fractal plotter... "Chris M. Thomasson" <ahh_f_it@crap.nothing> - 2019-01-26 18:21 -0800
  Re: Simple 2d C99 fractal plotter... "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-01-28 22:20 -0800
    Re: Simple 2d C99 fractal plotter... "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-01-28 22:55 -0800
      Re: Simple 2d C99 fractal plotter... "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-01-28 23:03 -0800
    Re: Simple 2d C99 fractal plotter... "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-02-06 22:37 -0800
      Re: Simple 2d C99 fractal plotter... "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-02-11 13:44 -0800

csiph-web