Re: Convert color-image to bw *fast*

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

"Joergen Bech @ post1.tele.dk>" <jbech<NOSPAMNOSPAM> wrote in message
news:k20kk29s1cf4cenllgjnlbvo0rjr5easid@xxxxxxxxxx
The result are then

Float: 661
Double: 569
Integer: 370

I found a few problems in your test. The first I found when I ran your test
and got no results, took me a while to figure out you were using
Debug.WriteLine instead of Console.WriteLine so nothing was coming out in
release mode. The tests should probably be run in release. The second
problem I found was that all the code we were actually testing got optimised
out in release, the results were all around 200ms with random variations of
up to 40ms. The other problem I found was red, green and blue were constant
values of zero so probably also optimised out. If they were not optimised
out then they *might* favour the doubles. Red, green and blue were ints but
in the original problem they were bytes. I changed the code so the
double/float/int value goes into a variable, just to make sure we are
actually dealing with the correct datatype and the compiler isn't doing some
optimisations.

Although with all the changes I got even closer results than you and am not
sure my tests are any more valid :-) I think that would be due to the extra
code I've added inside the loop to ensure everything gets executed and the
rgb values get incremented.

Double: 7266
Float: 9406
Int: 6578

The results basically agree with your assesment on floats and doubles are
suprisingly close to ints. I find these results quite odd though, double is
64 bit and int is of course 32. Surely just that would be enough to make it
slower (although I guess this is reflected in your results of 569 vs 370).
In the actual real life test comparing the processing of my large bitmap
between ints and doubles (both inline and the /255 removed) I got 78ms vs
125ms. Not a lot of difference but still 50% faster. For a high level
language c# does pretty well, I calculated that it was executing each
iteration of your loops in 12 instructions. :-)

Michael


.

Relevant Pages

  • Re: RAD vs. performance
    ... I'm happy to say that ints, floats and sets are not all ... then that's assuming the programmer actually needs a float. ... all is not lost in OCaml. ... Because you need whole-program optimisation for a start. ...
    (comp.lang.misc)
  • Re: dynamic vs. static: the age-old debate
    ... a bignum type in OCaml that has the same operations as ints (including ... I suppose there aren't a lot of algorithms for ints other than ... but I've already stated that it's not a standard float. ... what are the differences in the semantics between ...
    (comp.lang.misc)
  • Re: RAD vs. performance
    ... I've never noticed code repetition between int and float types. ... should the elements be ints ... So can dynamic typing, if designed correctly. ... Because you need whole-program optimisation for a start. ...
    (comp.lang.misc)
  • Re: libc/printf bug
    ... How would you print a float in hex? ... So if you wite %x the thing will increment stackpointer by some bytes to ... rules are different, floats become doubles, char/short become ints and similar. ...
    (comp.os.linux.development.apps)
  • Re: RAD vs. performance
    ... I'm happy to say that ints, ... whole-program optimisations on my OCaml code. ... Pd is written in a dynamic language with ... whole program optimisation, whereas Ps is written in a statically typed ...
    (comp.lang.misc)