Thread: a few opengl(or general programming) questions

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Registered User linuxdude's Avatar
    Join Date
    Mar 2003
    Location
    Louisiana
    Posts
    926

    a few opengl(or general programming) questions

    Most Opengl functions take floats as there arguments. I have been programming and what I have noticed is some people pass arguments with the f ex:
    Code:
    glColor3f(0.0f,0.0f,1.0f);
    I just use 0.0,0.0,1.0
    I know these are doubles but is it bad not to implicity tell them the argument is a float?
    --AND--
    Code:
    fread(&image->sizeY, 4, 1, file))
    I found this on NeHe and was wondering. Isn't this bad practice, the second argument that is? Shouldn't it be sizeof(unsigned int) and not 4?

  2. #2
    Banned
    Join Date
    May 2004
    Posts
    129
    They are not doubles, they are floats, and I believe the postfix .0f just tells the compiler that there is definitely nothing beyond the last decimal place given.

    For the second one, most would say yes, it is bad practice, but you will hardly ever get burned for it. In an ideal world, you will always use the sizeof() operator, but I wouldn't worry about it too much otherwise.

    edit

    until you get a job writing the next distribution of linux at your multi million dollar programming agency. In that case, always use sizeof, just to seem more professional

  3. #3
    Registered User linuxdude's Avatar
    Join Date
    Mar 2003
    Location
    Louisiana
    Posts
    926
    ok I was just checking myself. I am still wondering on the first question thouhg
    Floating-point constants contain a decimal point (123.4) or an exponent (1e-2) or both; their type is double, unless suffixed. The suffisxes f or F indicate a float constant; l or L indicate a long double.
    Source: The C Programming Language 2ed
    I was thinking that is it possible for a conversion error to occur when I pass doubles?

  4. #4
    Banned
    Join Date
    May 2004
    Posts
    129
    A 'float' and a 'double' are both two different types of decimals, with the latter having double the precision. By this definition, they are not the same, but if you ask 'double' to be a generic term for 'decimal', then yes they are both doubles.

    edit

    in short, a 32bit float cannot ever have the same precision as the 64 bit double

    edit again

    You should not get a conversion error, most compilers will just give about 80,000 warnings about truncations (for visual studio, this depends on your warning level).
    Last edited by vNvNation; 06-11-2004 at 04:26 PM.

  5. #5
    Registered User linuxdude's Avatar
    Join Date
    Mar 2003
    Location
    Louisiana
    Posts
    926
    I guess I'll start adding the f. I compile with -Wall -pedantic and I don't get any warnings.

  6. #6
    l'Anziano DavidP's Avatar
    Join Date
    Aug 2001
    Location
    Plano, Texas, United States
    Posts
    2,743
    0.0 = double
    0.0f = float

    Yes use the f's. Not only will it be easier on the compiler but I believe it was probably also give you a notch or two on speed at runtime....depends on the compiler.....
    My Website

    "Circular logic is good because it is."

  7. #7
    Has a Masters in B.S.
    Join Date
    Aug 2001
    Posts
    2,263
    the 'f' suffix, tells the compiler to handle the literal as a float instead of its default double handling...

    on the second question, no its not necessarily bad practice,
    this idea i think is a carry-over from memory allocation where specifing the actual size of the type is critical, otherwise it depends on context... if you decide to compile this on a different computer sometime, think of it like this, if the data in the file is written as four bytes and the sizeof(unsigned int) happens to be 8 on some other machine... then you can imagine the trouble... maybe they should use a define or something for the size but... its not necessarily bad practice.

    btw: um the f suffix should give no runtime speed change, and should give little or no compile time change as far as i know(i could be wrong) its just for warning supression... because most compilers treat float point literals as doubles by default.
    Last edited by no-one; 06-11-2004 at 07:16 PM.

  8. #8
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    Well the reason we got into it was because I posted over at flashdaddee that doubles were faster because I read that somewhere. He insisted that floats were and when we tested code we found out that we were both wrong.

    But you can still find this misinformation all over the place and I've even found it in some of my 3D books. Perhaps it is slower for a video card to process 64 bits at a time rather than 32 or perhaps it has something to do with the AGP bus - but at a CPU level there is no diff.

  9. #9
    Banned
    Join Date
    May 2004
    Posts
    129
    Agreed.

  10. #10
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    alright, heres my 2 cents, just for the sake of argument.

    while at the CPU level floats and doubles may have (essentially) equal performance, doubles still take twice the memory space. thus, when memory is accessed only half the number of doubles will make it over the BUS to cache as will floats. In short, to access the same number of floats as doubles you will have to access memory more times (assuming you access enough to cause more than one BUS ride)

    heres a simple example to clarify what im saying,
    Lets say BUS is 16 bytes wide. One memory access will get 2 doubles or 4 floats. If you access 4 doubles from an array and 4 floats from an array, the float access will cause one BUS transaction while the double access will cause 2. More trips to memory will amount to slower performance. If there are little blue dots on your bread or little green ones on your cheese you shouldnt eat it.

  11. #11
    I thought that if the parameters to the function were floats that if you passed a double to it it would convert it to a float.

  12. #12
    Registered User linuxdude's Avatar
    Join Date
    Mar 2003
    Location
    Louisiana
    Posts
    926
    that's what I assume

  13. #13
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    Quote Originally Posted by bludstayne
    I thought that if the parameters to the function were floats that if you passed a double to it it would convert it to a float.
    it will, you might get a compiler warning though.

  14. #14
    Then why does it matter if you pass the parameters with the suffix or not?

  15. #15
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    while at the CPU level floats and doubles may have (essentially) equal performance,
    There is nothing essentially about it - they have equal performance. Since the Intel docs specify that even an m32real and m64real being loaded from memory perform at exactly the same speed. Regardless of bus the CPU has been designed so that a float fetch or a double fetch as it relates to pushing values onto the FPU stack (keep in mind this only applies for pushing values onto ST(0)) operate at the same speed. If this were not true then the clocks would change.

    I'm quite sure that motherboard manufacturers have taken into consideration the design of the CPU and the FPU so that what Intel says...happens on the board. The CPU can fetch a double and a float at the same speed. Perhaps this is accomplished by actually slowing down the float fetch to equal the double fetch thereby making them look like they perform equivalently...but I doubt it. Perhaps there is some SIMD taking place under the hood of the modern FPU which allows a single instruction but multiple data in one fetch over the bus. MMX performs somewhat of the same operations via the FPU as well.

    This would lend credence to the fact that perhaps our CPUs ARE currently capable of performing a 64-bit fetch....but Intel has only enabled it for the FPU. This would follow with the Intel design philosophy since most, if not all, of their CPUs in the past have been able to do much more than was ever supported. For instance early CPUs like the 8088 had a 16 bit bus.....but internally actually had a 32-bit bus and could fetch 32-bits at a

    time...but the 32-bit registers were not exposed to the programmer nor were the 32-bit fetch opcodes. It is quite possible and probably that given the design of MMX/SSE/SSE2 and the FPU that perhaps the CPU is performing a 64-bit fetch, but only using these opcodes. The 64-bit fetch is not supported on 32-bit CPUs and is not apparent to the programmer.....but I bet that is exactly what is happening internally to the CPU.

    Why did they not enable 64-bit fetches for memory....I have no idea. My guess would be marketing strategy. Also it is quite possible that the new 64-bit CPUs actually have 128-bit fetches. Whatever the case...there is more going on internally than Intel is telling me in the book. Otherwise MMX/SSE/SSE2 and FPU opcodes would pose little to no advantage over the standard 32-bit x86 opcodes. Is it not peculiar how suddenly with MMX we can operate on 64 bits at a time and yet do so at blazing speeds over a 32-bit bus??? Something's fishy there.

    Also this float and double data type stuff is compiler side stuff. To load either a 32-bit or 64-bit floating point value you must use FLD. Your compiler is using this somewhere so it doesn't matter assembler side whether it is 32-bits or 64...its going to use the FLD instruction and the FPU will zero fill the insignificant bits in your value. I think that it might zero extend the value but I'm not sure and I'm not sure if you can zero extend a floating point value.

    If the bus were a factor then the clock speeds would be different for loading from memory and they are not.
    Last edited by VirtualAce; 06-14-2004 at 08:00 AM.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. questions....so many questions about random numbers....
    By face_master in forum C++ Programming
    Replies: 2
    Last Post: 07-30-2009, 08:47 AM
  2. A very long list of questions... maybe to long...
    By Ravens'sWrath in forum C Programming
    Replies: 16
    Last Post: 05-16-2007, 05:36 AM
  3. Several Questions, main one is about protected memory
    By Tron 9000 in forum C Programming
    Replies: 3
    Last Post: 06-02-2005, 07:42 AM
  4. Trivial questions - what to do?
    By Aerie in forum A Brief History of Cprogramming.com
    Replies: 23
    Last Post: 12-26-2004, 09:44 AM
  5. questions questions questions.....
    By mfc2themax in forum A Brief History of Cprogramming.com
    Replies: 1
    Last Post: 08-14-2001, 07:22 AM