Hey im just asking a quick question im getting a compiler error for shift a double or multiplying it by 1024
basically its like.
it doesnt work the error says it needs to be an int or enum but if cast an INT then my answer is like 0 in yy[0]Code:static double xx[] {0.9999}; int yy[1]; yy[0] = xx[0] << 10;
So multiply by 1024.
There is no shifting for doubles.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
its really for speed purposes that im shifting i mean i know i could multiply it by 1024 but im trying to make it faster
Do you know about co-processors?
Do you know about instruction rescheduling?
In some circumstances, the cost to you is zero.
And how do you know this simple operation is the huge bottle-neck in the performance of your program?
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Shifting the bit pattern of an IEEE float (or any float, probably) doesn't multiply it with anything, it just ruins it.Originally Posted by kiros88
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
That's as fast as it gets. I've already searched high and low for the exact thing you seek as part of my software 3D engine, and something faster simply doesn't exist. The only faster options are to do many of them in parallel, or to avoid doing it at all.
You should post some actual code snippet so that we can see things that can be optimised further rather than things that can't such as this. For example, I was able to reorder my inner loop, performing an extra divide per pixel span, but ending up gaining about 9fps because the CPU was able to overlap the floating point divide with integer instructions. (The same optimisation used in Quake, but without resorting to assembly for it!)
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
*1024 would be equivalent to adding 10 to the exponent.
But since the exponent isn't even byte aligned within a double, you'd have to resort to a lot of bit stuffing magic just to try it.
Then you're making a lot of assumptions about the internal format of doubles, with no obvious guarantee that it would be any better for you.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
O_o
Before you could use any simple shift or bit fiddling mechanism you'd have to know that the values you are operating on fall within a certain range. If the value is outside this range you'll get "weird" results.
That said, I use a hack (below) for a lot of systems. I doubt it will be faster than simply multiplying for any desktop chip.
Soma
Code:#include <iostream> #include <sstream> typedef unsigned long long uint64_t; static const uint64_t IEEELFMUL1024(0xA0000000000000LLU); int main ( int argc , char ** argv ) { union { uint64_t qword; double value; }; if(2 == argc) { std::istringstream sin(argv[1]); sin >> value; } else { std::cin >> value; } qword += IEEELFMUL1024; std::cout << value << '\n'; return(0); }
If you do something like this, you might make your program 0.1% faster. Or, you could post your code, and somebody here could tell you how to make your program 10000% faster. Who knows.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Heh - ain't that the truth.
Sounds just like a "can you make this comparison faster" type of question, only to discover later that the problem was "comparison inside a bubble sort".
@OP - tell us the whole problem, not the minutiae of some trivial machine operation.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
