How to make code block works faster?
-
or may be this: b = (a > 255 : 255 : (a <= 0 ? 0 : (BYTE)a)); Gurmeet
BTW, can Google help me search my lost pajamas?
My Articles: HTML Reader C++ Class Library, Numeric Edit Control
-
you find this elegant ????????? i agree the ?: operator is elegant when you have few (less than 2) conditions, but it becomes really unreadable otherwise. more, it uses exactly the same time as the previous post's code. what i prefer is expanding the code, but placing the { }. it doesn't eat bread and it is really more easy to debug. one last thing. the first written code is (by my thinking quite fast). you can so let it like this :
if (a > 0) {
if (a > 255) {
b = 255;
}
else {
b = (BYTE)a;
}
}
else {
b = 0;
}
TOXCCT >>> GEII power
Actually, it's 2 _more_ instructions than the previous code. ;) I was really only kidding, I would never put that into production code... :suss: On a side note, I see you are a same-line bracer :eek: the horror! I'd much rather wade through deeply obfuscated code than to subject my tender eyes to such bracing schemes... ;P ~Nitron.
ññòòïðïðB A
start -
Actually, it's 2 _more_ instructions than the previous code. ;) I was really only kidding, I would never put that into production code... :suss: On a side note, I see you are a same-line bracer :eek: the horror! I'd much rather wade through deeply obfuscated code than to subject my tender eyes to such bracing schemes... ;P ~Nitron.
ññòòïðïðB A
start -
Nitron wrote: I see you are a same-line bracer where, which ? what is wrong in my code ? i don't exactly understand your sentence. could you rephrase it please ?
TOXCCT >>> GEII power
You do this:
if (a > 0) {
if (a > 255) {
b = 255;
}
else {
b = (BYTE)a;
}
}
else {
b = 0;}instead of this:
if (a > 0)
{
if (a > 255)
b = 255;
else
b = (BYTE)a;
}
else
b = 0;i.e. you put your opening braces on the same line as your conditional statement. ~Nitron.
ññòòïðïðB A
start -
You do this:
if (a > 0) {
if (a > 255) {
b = 255;
}
else {
b = (BYTE)a;
}
}
else {
b = 0;}instead of this:
if (a > 0)
{
if (a > 255)
b = 255;
else
b = (BYTE)a;
}
else
b = 0;i.e. you put your opening braces on the same line as your conditional statement. ~Nitron.
ññòòïðïðB A
startand so what ??? didn't you ever saw that ?? is it a code fault ? pfffffff poor guy. moreover, i said that it was more readable to write the code with the braces. when you cat multiple if statements, we are not sure to whose if the esle is associated with. My code is correct, if you don't like this, it's your point of view, but it is efficient ! :mad:
TOXCCT >>> GEII power
-
and so what ??? didn't you ever saw that ?? is it a code fault ? pfffffff poor guy. moreover, i said that it was more readable to write the code with the braces. when you cat multiple if statements, we are not sure to whose if the esle is associated with. My code is correct, if you don't like this, it's your point of view, but it is efficient ! :mad:
TOXCCT >>> GEII power
-
I have such block: if (a > 0) if (a > 255) b = 255; else b = (BYTE)a; else b = 0; do anyone have an idea, how to make it works faster? Thanx.
if (a > 0) { if (a > 255) b = 255; else b = (BYTE)a; } else b = 0; This is what you are attempting to accomplish? Number of Instructions != speed, btw. However, if you really want to optimize it that bad I would write it directly in assembly yourself. The assembly generated by any proposed solultion will also depend on the compiler options and the surrounding code. So, you can't trust what someone else says is smaller for them obviously because they can be optimized differently depending on the surrounding code. Here's some examples: DWORD func(DWORD b, DWORD a) { if (a > 0) { if (a > 255) b = 255; else b = (BYTE)a; } else b = 0; return b; } DWORD func2(DWORD b, DWORD a) { if(b = a) { if(a > 255) // if a was a WORD, if (a & 0xFF00) faster? { b = 255; } else { b &= 0xFF; } } return b; } DWORD func3(DWORD b, DWORD a) { if(b = a) { b &= 0xFF; if(a > b) { b = 255; // or is "b |= 255 faster?" } } return b; } DWORD func4(DWORD b, DWORD a) { b = 0; if(a) { if(!(b = a & 0xFF)) { b = 255; // or is "b |= 255 faster?" } } return b; } assembly: func: 004012b0 8b442408 mov eax,[esp+0x8] 004012b4 85c0 test eax,eax 004012b6 7617 jbe dptest!func+0x1f (004012cf) 004012b8 3dff000000 cmp eax,0xff 004012bd 7608 jbe dptest!func+0x17 (004012c7) 004012bf b8ff000000 mov eax,0xff 004012c4 c20800 ret 0x8 004012c7 25ff000000 and eax,0xff 004012cc c20800 ret 0x8 004012cf 33c0 xor eax,eax 004012d1 c20800 ret 0x8 func2: 004012e0 8b442408 mov eax,[esp+0x8] 004012e4 85c0 test eax,eax 004012e6 7414 jz dptest!func2+0x1c (004012fc) 004012e8 3dff000000 cmp eax,0xff 004012ed 7608 jbe dptest!func2+0x17 (004012f7) 004012ef b8ff000000 mov eax,0xff 004012f4 c20800 ret 0x8 004012f7 25ff000000 and eax,0xff 004012fc c20800 ret 0x8 As you can see, the assembly was optimized to not penalize for A = B in the first if. That's because we're returning the end result, so we can have it optimized. func3: 00401300 8b4c2408 mov ecx,[esp+0x8] 00401304 85c9
-
I have such block: if (a > 0) if (a > 255) b = 255; else b = (BYTE)a; else b = 0; do anyone have an idea, how to make it works faster? Thanx.
I really don't know why you want to optimize this code!? give me the whole code of the function. Don't try it, just do it! ;-)
-
I really don't know why you want to optimize this code!? give me the whole code of the function. Don't try it, just do it! ;-)
-
I have seen this kind of problem before, where when manipulating matrix values, an inordinate amount of time is spent during the conversion of data types: floats to ints, for example. I hope your compiler isn't keeping "255" as an int and converting it to "255.0f" for every comparison. Certainly the compiler should be smarter than that. If all the "a" values are floats, then your conversion to BYTE doesn't maintain any of the decimal portions of the "a" values. Therefore, why does "a" need to be a float? Could everything else be made to work properly if "a" was not a float? You may also consider a simpler comparison structure that eliminates the "else" statements. Using "else" complicates the control flow, such that during a pre-fetch lookup, the CPU can't know which path it is going to take. When I was writing code for a DSP, this was a big concern. A statement like
if (a < 0) b = 0;was able to be optimized better thanif (a > 0) {...} else b = 0;because of the single statement (not a block) and not having an "else". I don't know if this strategy will help you on a normal PC. Depending on the constraints on "b", you could try:b = (BYTE) a; if (a < 0.0f) b = 0; if (a > 255.0f) b = 255;At least on a DSP, while it seems that a test may be performed unnecessariyly, it was actually faster because of the improvements in control flow. I don't know what tool you are using to test your performance, but you may want to try the Memory Validator that is advertised here on CodeProject. Good luck. Dave "You can say that again." -- Dept. of Redundancy Dept.With the above proposition you are always executing b = (BYTE) a; This is the bottleneck within the code segment. I know it will all depend on the values of a as to how relevant this would be, but it is a factor. Ant.
-
Chances are most of your time is spent in "b = (BYTE) a". This is probably using "ftol" which is very slow. Because of the C/C++ standard, the ftol must change the FPU settings before and after converting the value to an integer. Thus there is a LOT of wasted time. Search google for "fast ftol". Tim Smith I'm going to patent thought. I have yet to see any prior art.
I agree it definately will be this conversion. Ant.
-
Please read my response. You can make "b = (BYTE) a " a LOT faster. It involves using a "fast ftol". Search google for that phrase. Tim Smith I'm going to patent thought. I have yet to see any prior art.
I think you use static_cast rather than C style casts and ass /Qifist as a compiler swich to swich it on. Or use assembly #pragma warning (disable:4035) __declspec( naked ) long Q_ftol( float f ) { static int tmp; __asm fld dword ptr [esp+4] __asm fistp tmp __asm mov eax, tmp __asm ret }