Integer VS Fpu
category: general [glöplog]
Go Gerard Go! :D
this thread seems like optimus vs plek and plek is
winning:D
winning:D
Nothing wrong with asking questions, but don't try to bash stuff just because it hits you in your face.
OPTIMUS! COME OVER HERE!
how is that possible ? you have no time to answer my email about your blob intro, but start a speculative thread about fixed/floating-point which you cannot follow because you are too occupied,
but then participate as if the occupation had gone instantly! HOW ABOUT ANSWERING MY MAIL ? DON'T YOU WANT SOME SCENE ATTENTION ? NOW YOU HAVE MY ATTENTION! START TO DISCUSS THE CODE IMMEDIATELEY! FEAR MY NINJA SKILLZ!
how is that possible ? you have no time to answer my email about your blob intro, but start a speculative thread about fixed/floating-point which you cannot follow because you are too occupied,
but then participate as if the occupation had gone instantly! HOW ABOUT ANSWERING MY MAIL ? DON'T YOU WANT SOME SCENE ATTENTION ? NOW YOU HAVE MY ATTENTION! START TO DISCUSS THE CODE IMMEDIATELEY! FEAR MY NINJA SKILLZ!
This discussion is foolishnes. Everyone knows that you aren't a REAL programmer unless you enter your program in binary using switches on the front panel.
Wait, scratch that. You aren't a REAL programmer unless you build your own hardware. Why use Intel's lame CPU's when you can build your own?
As long as you are building the CPU, might as well make your own transistors as well. I mean, why trust the electronics companies to do stuff like that for you?
Heck, why even use natural silicon? You should build your own sun to build silicon atoms from hydrogen...
Whlie you are at it, why not make your own universe? Only GODS can be REAL programmers.
Wait, scratch that. You aren't a REAL programmer unless you build your own hardware. Why use Intel's lame CPU's when you can build your own?
As long as you are building the CPU, might as well make your own transistors as well. I mean, why trust the electronics companies to do stuff like that for you?
Heck, why even use natural silicon? You should build your own sun to build silicon atoms from hydrogen...
Whlie you are at it, why not make your own universe? Only GODS can be REAL programmers.
only real programmers can be gods.
Optimus said:
"I can code some stupid plasmas and did checks with FPU and Integer and I found out that FPU sucs! Well,. it's impressively fast here on my Athlon but integer still does it better! At least for the kind of effect I tried as a test.."
Sagacity says:
Well, I'm not one to pass judgement, but I think it's fair to say your tests suck. Can you post the code to your tests so we can help point out errors (*)?
(*) Possibly laugh at them
"I can code some stupid plasmas and did checks with FPU and Integer and I found out that FPU sucs! Well,. it's impressively fast here on my Athlon but integer still does it better! At least for the kind of effect I tried as a test.."
Sagacity says:
Well, I'm not one to pass judgement, but I think it's fair to say your tests suck. Can you post the code to your tests so we can help point out errors (*)?
(*) Possibly laugh at them
:If you insist on /nodefaultlib (are you optimizing for size?) then consider something like:
#if defined(__cplusplus)
extern "C" {
#endif
int _fltused;
#if defined(__cplusplus)
};
#endif
This fltused "flag" lets the linker know about fp.
Of course, with /nodefaultlib you'll have to implement a whole bunch of standard library stuff which generally isn't exactly fun =)
Additionally, you (Opti) rant about optimizing, yet seek an interface with just a putpixel function... Kind of contradictory don't you think?
Personally, cpp makes my life infinitely easier. Read the cpp faq lite and learn OOP which will drastically improve the usability of your code.
Just out of curiosity, what scene prods use tinyptc?
#if defined(__cplusplus)
extern "C" {
#endif
int _fltused;
#if defined(__cplusplus)
};
#endif
This fltused "flag" lets the linker know about fp.
Of course, with /nodefaultlib you'll have to implement a whole bunch of standard library stuff which generally isn't exactly fun =)
Additionally, you (Opti) rant about optimizing, yet seek an interface with just a putpixel function... Kind of contradictory don't you think?
Personally, cpp makes my life infinitely easier. Read the cpp faq lite and learn OOP which will drastically improve the usability of your code.
Just out of curiosity, what scene prods use tinyptc?
>As long as you are building the CPU, might as well make your own transistors as well.
Now that the discussion brought it: Btw,. did you know that we were expecting our Nasty Bugs demo at ReAct from our new coder? (While I was scratching my balls and coding some C64 instead of helping ;) Hahaha!!! I have learned that we want see a demo, instead he started building a CPU instead =)
Perhaps we will release a wild CPU build demo ;)
>putpixel
UHM,. Forget that! I know that putpixel sucks. I just mentioned it upon my korilla, makes no sense now. Afteralls I never use it even under quickbasic. I didn't need to answer to that however since it's too obvious I said it jff..
Now that the discussion brought it: Btw,. did you know that we were expecting our Nasty Bugs demo at ReAct from our new coder? (While I was scratching my balls and coding some C64 instead of helping ;) Hahaha!!! I have learned that we want see a demo, instead he started building a CPU instead =)
Perhaps we will release a wild CPU build demo ;)
>putpixel
UHM,. Forget that! I know that putpixel sucks. I just mentioned it upon my korilla, makes no sense now. Afteralls I never use it even under quickbasic. I didn't need to answer to that however since it's too obvious I said it jff..
At BASICity:
Well,. let's see that, since I am too curious how a plain simple integer routine can go faster with FPU, because it's so plain that it can't go further anymore..
..going to the other computer.
..coming back after some more tests.
I have to admit that FPU is just a bit faster on my Athlon and the same on the Pentium 2 :/
I forgot an important detail. Without the conversions. Zbs I had the code:
Just tables and additions, and you see I have // the output, because it wants integers and it won't work now. I had also an increasing white line at each frame and after 10 line draws, I counted the time, because I don't have a frames per second counter yet. The current programm does 40 seconds to finish the 10 lines, if we put int to r,g,b and the fsin arrays, we get 48 seconds. So, you are right! :P
But then, if I want to have an actuall effect, r,g,b should be integer. Make them int r,g,b; un-// the output to see something. With float fsin arrays and int r,g,b, the effect is much slower than with all integer! Uhm,. the conversions from fpu to int :P
I also tested it on my Pentium2, and the pure example (without conversion, without output) has exactly the same speed with integer. So, you are still right..
Still. The conversions from float to r,g,b
But if you tell me how to have an output by avoiding the slow conversions, if I can have something actual shown on the screen without getting it all slow down, then I will consider coding FPU or what prooves faster for both my Athlon and the Pentium 2. I'd love to learn something from this stupid thread I started afterall..
Btw, btw, btw,. another curious question:
The TinyPTC example declares this array: int pixel[SIZE];
This is the gfx buffer array and if I recall well, I am just working on 32bit mode. So why the hell is it an integer(16bit) and not a long int(32bit)??? (Except if integers are 32bit in C++. At least in Java, I think they are. Btw2, someone told me that the meaning of the term "word", depends on the bits of a computer, it's not just always 16bit but 32bit in some other nonPC systems. Is it true?)
Well,. let's see that, since I am too curious how a plain simple integer routine can go faster with FPU, because it's so plain that it can't go further anymore..
..going to the other computer.
..coming back after some more tests.
I have to admit that FPU is just a bit faster on my Athlon and the same on the Pentium 2 :/
I forgot an important detail. Without the conversions. Zbs I had the code:
Code:
//
#include "tinyptc.h"
#include <math.h>
#define WIDTH 800
#define HEIGHT 600
#define SIZE WIDTH*HEIGHT
int x,y,i,k=0;
float r,g,b;
int pixel[SIZE];
float fsin1[16384],fsin2[16384],fsin3[16384];
unsigned char fpal[512];
int main()
{
for (i=0;i<16384;i++)
{
fsin1[i]=sin(i/85.0)*256.0+256.0;
fsin2[i]=sin(i/75.0)*128.0+128.0;
fsin3[i]=sin(i/35.0)*64.0+64.0;
}
if (!ptc_open("test",WIDTH,HEIGHT)) return 1;
while (1)
{
i=0;
for (y=10;y<HEIGHT;y++)
{
for (x=0;x<WIDTH;x++)
{
r=fsin1[x]+fsin2[y]+fsin3[x+y+k]+fsin2[x+y+k+k];
g=fsin1[x]+fsin3[y]+fsin1[x+k]+fsin2[y+k+k];
b=fsin3[x]+fsin2[y]+fsin2[x+y+k+k]+fsin2[x+k+k];
// pixel[i] = (r<<16) | (g<<8) | b;
i++;
}
}
ptc_update(pixel);
if (k<10*WIDTH) pixel[i+k]=(255<<16) | (255<<8) | 255;;
k++;
}
}
Just tables and additions, and you see I have // the output, because it wants integers and it won't work now. I had also an increasing white line at each frame and after 10 line draws, I counted the time, because I don't have a frames per second counter yet. The current programm does 40 seconds to finish the 10 lines, if we put int to r,g,b and the fsin arrays, we get 48 seconds. So, you are right! :P
But then, if I want to have an actuall effect, r,g,b should be integer. Make them int r,g,b; un-// the output to see something. With float fsin arrays and int r,g,b, the effect is much slower than with all integer! Uhm,. the conversions from fpu to int :P
I also tested it on my Pentium2, and the pure example (without conversion, without output) has exactly the same speed with integer. So, you are still right..
Still. The conversions from float to r,g,b
But if you tell me how to have an output by avoiding the slow conversions, if I can have something actual shown on the screen without getting it all slow down, then I will consider coding FPU or what prooves faster for both my Athlon and the Pentium 2. I'd love to learn something from this stupid thread I started afterall..
Btw, btw, btw,. another curious question:
The TinyPTC example declares this array: int pixel[SIZE];
This is the gfx buffer array and if I recall well, I am just working on 32bit mode. So why the hell is it an integer(16bit) and not a long int(32bit)??? (Except if integers are 32bit in C++. At least in Java, I think they are. Btw2, someone told me that the meaning of the term "word", depends on the bits of a computer, it's not just always 16bit but 32bit in some other nonPC systems. Is it true?)
Perhaps I can look with pointers at the place where the fpu results of the pixel colors are stored and get the integer part myself? Mmm..
integers are 32bit on x86
obviously 80286 isn't x86 then
kusma, isn't "integer" a datatype defined by your favorite programming language? :-)
Optimus: Have a look at your "test". Everything you do (in the main loop) is adding up numbers, that you read from tables. So well... adding numbers is about equally fast, no matter whether you do it in FPU or ALU (integer). So the only problem you might encounter in your "test" is cache-misses. But look, you are reading quite linearly from memory (as I see), and thus work quite cache-friendly, so... moving the sin into the inner loop will probably decrease the speed, and thus not prove the superiority of FPU ;-)
You know, a discussion about float vs. int is only reasonable if you do some calculations except adding, like dividing, multiplying, calculating sin and so on. I mean, a "mathematical" effect. Your "test" only shows that caches are worth their money :-)
So, you seem not to have a basic understanding of modern processors. Maybe a look at the intel optimization pages might help improving your code.
You know, a discussion about float vs. int is only reasonable if you do some calculations except adding, like dividing, multiplying, calculating sin and so on. I mean, a "mathematical" effect. Your "test" only shows that caches are worth their money :-)
So, you seem not to have a basic understanding of modern processors. Maybe a look at the intel optimization pages might help improving your code.
obviously that test is completely useless, optimus, try doing even a moderatly complex 3d-engine w/o the FPU and then get back to us.
A C++ book from my university says that integers are 16bit and if you want to declare a 32bit integer, you write "long int" or something. Go figure..
As for the rest, I know that with multiplies and divisions, FPU can be faster, I have thought that before giving you the test, but that prooves that for simple things like these (and most of the 2d effects I have coded on Quickbasic), integer is still better :P
As for the rest, I know that with multiplies and divisions, FPU can be faster, I have thought that before giving you the test, but that prooves that for simple things like these (and most of the 2d effects I have coded on Quickbasic), integer is still better :P
So, to simple say: FPU is better and do everything with FPU sucks..
Dear lord, you call that a *test*? :)
Nice pitfall there Optimus. What Chock said :)
Nice pitfall there Optimus. What Chock said :)
nice to see someone judging the FPU without basically using it properly :D
optimus, on 32bit platforms integers became 32bit. old dos-compiler treat integers as 16 bit value, but today there is no difference between long int and a normal int. it is both signed 32bit by default. afaik in java long = 64 bit.
get another book...
get another book...
Optimus: I think you still don´t get it. If you want to add two integers, then you shouldn´t do it with the FPU like
int j = (int)(2.0 * 3.0);
but no one here wanted to suggest that. And that also never was questioned. The question is, if you want to use non-integers (rational numbers) whether you do it floating point or fixed point, like if you better write
float d = 2.7 * 5.3;
or, with 24:8 fixed point
int i = (691 * 1357) >> 8;
which is basically the same calculation. And ten years ago, we used the second method, as floating point was awfully slow. Now we use the first one (at least the newschool kiddies :-), because today FPU is about as fast as ALU (which was different on 486 or even 387), and much simpler to use. That´s all.
int j = (int)(2.0 * 3.0);
but no one here wanted to suggest that. And that also never was questioned. The question is, if you want to use non-integers (rational numbers) whether you do it floating point or fixed point, like if you better write
float d = 2.7 * 5.3;
or, with 24:8 fixed point
int i = (691 * 1357) >> 8;
which is basically the same calculation. And ten years ago, we used the second method, as floating point was awfully slow. Now we use the first one (at least the newschool kiddies :-), because today FPU is about as fast as ALU (which was different on 486 or even 387), and much simpler to use. That´s all.
Anyway, on amiga fpu is damned slow :)
yeah.. one frame per instruction rocks... or .. fail on the bigscreen
nice one btw ;) memories...
