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

Groups > comp.lang.c > #53551

Re: harder case for optimization

Show all headers | View raw

W dniu piątek, 28 listopada 2014 01:56:56 UTC+1 użytkownik Bart napisał:
> "David Brown" <david.brown@hesbynett.no> wrote in message
> news:m58d4p$o83$1@dont-email.me...
> > On 27/11/14 23:07, BartC wrote:
> 
> >>
> >> For each iteration, it will effectively add (head_x, head_y, head_z) to
> >> dir.
> >> So instead of the above, why not initialise dir in ...B. Then after the
> >> call
> >> to table_normalize(&dir), do:
> >>
> >>   dir.x += head.x;
> >>   dir.y += head.y;
> >>   dir.z += head.z;
> >>
> >> which saves a multiply (actually, three multiplies).
> >>
> >
> > Doing this transformation is risky - you will build up rounding errors,
> > and lose precision.  Floating point does not work like "real" mathematics!
> 
> I think in this application, and for an inner loop of a thousand or so, it's
> probably not critical. (And 32-bits floats are used anyway which is already
> half the precision gone.)
> 
> (I have tested my idea, using floats and gcc -O0, and just that part of the
> loop the OP showed, but minus the sqrt calculation. My simplifications made
> it about 20% faster. It will be a tiny part of the whole app, but it all
> adds up.
> 
> Maybe gcc -O3 will do that job; maybe not.  Sometimes these simplications 
> in the source makes it easier to see where more pieces can come together and 
> more intermediate steps can be eliminated.
> 
> One note on that method: in the original, 'dir' is reset on each inner loop
> iteration. My way, because the scaling would modify it, the scaled version
> has to be created in a different 'dir'. 'dir' also needs to be initialised
> to ogon-head to avoid it being out of step, a consequence of the 0-based
> index.)
> 
mul to +=dx may be faster i think but not much (not tested yet), also float precission probably will suffice here, 

lets rethink it a bit

screen sizes are as screen sizes (4000x is a practical max i think so this is 23-12 = 11 bits lasting for 'subpixel' precision

if i count one bit of error after 4000 additions i should get error of 12 bits (?) it means 2 pixel range? comparing to the calculation in higher precision?

if all results in just streatching wiev by two pixels it is not to much important
worse it would be if it would be some fluctuations, but the fluctuations are probably not the case

not sure how addition would help to propagate this error compared to the multiply by i version (?)

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

Thread

harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-27 00:42 -0800
  Re: harder case for optimization "BartC" <bc@freeuk.com> - 2014-11-27 11:34 +0000
    Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-27 13:29 +0100
    Re: harder case for optimization Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-27 05:58 -0800
      Re: harder case for optimization Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-27 06:36 -0800
    Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-27 12:26 -0800
  Re: harder case for optimization "BartC" <bc@freeuk.com> - 2014-11-27 22:07 +0000
    Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-27 14:49 -0800
      Re: harder case for optimization "BartC" <bc@freeuk.com> - 2014-11-28 00:05 +0000
    Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-28 00:46 +0100
      Re: harder case for optimization "BartC" <bc@freeuk.com> - 2014-11-28 00:55 +0000
        Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-28 07:20 +0100
          Re: harder case for optimization Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-28 00:41 -0800
            Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-28 01:54 -0800
              Re: harder case for optimization Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-28 02:19 -0800
                Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-28 04:05 -0800
                Closed captioning (Was: harder case for something or other) gazelle@shell.xmission.com (Kenny McCormack) - 2014-11-28 12:15 +0000
                Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-28 06:11 -0800
              Re: harder case for optimization gazelle@shell.xmission.com (Kenny McCormack) - 2014-11-28 12:18 +0000
                Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-28 04:42 -0800
                Re: harder case for optimization gazelle@shell.xmission.com (Kenny McCormack) - 2014-11-28 16:37 +0000
                Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-28 08:48 -0800
                Re: harder case for optimization Kaz Kylheku <kaz@kylheku.com> - 2014-11-28 16:51 +0000
                Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-28 10:38 -0800
            Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-28 11:34 +0100
          Re: harder case for optimization "BartC" <bc@freeuk.com> - 2014-11-28 11:21 +0000
            Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-28 04:23 -0800
            Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-28 13:58 +0100
              Re: harder case for optimization "BartC" <bc@freeuk.com> - 2014-11-28 13:46 +0000
                Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-28 16:25 +0100
                Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-28 08:18 -0800
                Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-28 20:17 +0100
                Re: harder case for optimization Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-28 08:54 -0800
                Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-28 20:22 +0100
                Re: harder case for optimization Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-28 11:29 -0800
                Re: harder case for optimization Kaz Kylheku <kaz@kylheku.com> - 2014-11-28 19:51 +0000
                Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-28 20:58 +0100
                Re: harder case for optimization Melzzzzz <mel@zzzzz.com> - 2014-11-28 21:03 +0100
                Re: harder case for optimization Kaz Kylheku <kaz@kylheku.com> - 2014-11-28 20:11 +0000
                Re: harder case for optimization Melzzzzz <mel@zzzzz.com> - 2014-11-28 21:31 +0100
                Re: harder case for optimization "BartC" <bc@freeuk.com> - 2014-11-28 20:06 +0000
                Re: harder case for optimization "BartC" <bc@freeuk.com> - 2014-11-28 17:14 +0000
                Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-28 20:54 +0100
                Re: harder case for optimization "BartC" <bc@freeuk.com> - 2014-11-28 20:16 +0000
                Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-28 21:56 +0100
        Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-27 23:37 -0800
          Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-27 23:54 -0800
          Re: harder case for optimization BartC <bc@freeuk.com> - 2014-11-28 11:01 +0000
            Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-28 23:52 -0800
              Re: harder case for optimization Morris Dovey <mrdovey@iedu.com> - 2014-11-29 02:03 -0600
                Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-29 00:38 -0800
  Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-29 03:12 -0800
    Re: harder case for optimization BartC <bc@freeuk.com> - 2014-11-29 12:09 +0000
      Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-29 04:18 -0800
      Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-29 05:22 -0800
        Re: harder case for optimization BartC <bc@freeuk.com> - 2014-11-29 16:58 +0000
          Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-29 09:35 -0800
          Re: harder case for optimization Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-29 10:55 -0800
            Re: harder case for optimization BartC <bc@freeuk.com> - 2014-11-29 21:00 +0000
              Re: harder case for optimization Ian Collins <ian-news@hotmail.com> - 2014-11-30 11:25 +1300
                Re: harder case for optimization BartC <bc@freeuk.com> - 2014-11-29 22:56 +0000
                Re: harder case for optimization Ian Collins <ian-news@hotmail.com> - 2014-11-30 12:00 +1300
                Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-29 16:01 -0800
                Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-29 16:21 -0800
                Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-29 16:52 -0800
                Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-29 17:14 -0800
            Re: harder case for optimization glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-11-30 00:20 +0000
              Re: harder case for optimization Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-29 16:43 -0800
        Re: harder case for optimization Kaz Kylheku <kaz@kylheku.com> - 2014-11-29 17:29 +0000
  Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-12-05 02:12 -0800

csiph-web