Borland automatically adds exception code!?
My buddy at work claims that if you disable stack checking the exception cleanup code goes away. I forget the option, it''s something lik $s- in delphi.
Author
Mag:
Ahhh, that makes sense, as a lot of the extra code is just adding some local space on the stack and filling it. Cool stuff, man, thanks!
Kylotan:
From what I''ve read so far in this thread hasn''t given me any concrete arguments against using my pixel class.
Yes, I inline every function, because there are places any one of them could be called many times, but that''s an extra word of code/definition.
There''s not much room for compiler optimization, as the code is close to asm anyway. All of the asm I see being spit out is line for line the same thought process I had when writing the c++ code. To use the SIMD instructions, I would have to reorganize my code anyway. The only possible optimization I can see (though my Intel asm vocabulary basically stops after the i486), would be using MMX, but those need to be hand coded anyway, to my knowledge.
They are packed so that a 24-bit TPixel class uses 3 bytes, and there is no exception handling needed for any of the functions. This only takes 4 lines to do: 2 to set it up before the class and 2 to clean it up after.
There are no virtual functions, as the classes weren''t meant to be in an inheritance hirearchy. If that stack checking swtich works, and I think it should, there will be absolutely no extra overhead on top of manually manipulating 3 bytes seperately, and that''s considering you are only working on 24 bits. To encapsulate all current formats would require that you write individual image classes for each type of pixel format, for each type of image encoding. Using my pixel class, I only have to make a few specializations, and I can use the TPixel class for any image, accepting the type of component format as a template parameter.
Remember, I am doing a lot of software image manipulation, and the granularity here is necessary because when I''m writing my tri-linear interpolated image morphing code, I would rather see math performed on entire pixel objects with out worrying about the individual components. My image class has to be general enough to encapsulate any RGB(A) format, from using monochrome bits to GLfloats, and conversion is necessary in some cases, too. Based on all of the presented arguments, yours, mine, and all others here, I don''t think I''m all that crazy for using a pixel class.
Thank you for your interest, though, Kylotan.
Ahhh, that makes sense, as a lot of the extra code is just adding some local space on the stack and filling it. Cool stuff, man, thanks!
Kylotan:
From what I''ve read so far in this thread hasn''t given me any concrete arguments against using my pixel class.
Yes, I inline every function, because there are places any one of them could be called many times, but that''s an extra word of code/definition.
There''s not much room for compiler optimization, as the code is close to asm anyway. All of the asm I see being spit out is line for line the same thought process I had when writing the c++ code. To use the SIMD instructions, I would have to reorganize my code anyway. The only possible optimization I can see (though my Intel asm vocabulary basically stops after the i486), would be using MMX, but those need to be hand coded anyway, to my knowledge.
They are packed so that a 24-bit TPixel class uses 3 bytes, and there is no exception handling needed for any of the functions. This only takes 4 lines to do: 2 to set it up before the class and 2 to clean it up after.
There are no virtual functions, as the classes weren''t meant to be in an inheritance hirearchy. If that stack checking swtich works, and I think it should, there will be absolutely no extra overhead on top of manually manipulating 3 bytes seperately, and that''s considering you are only working on 24 bits. To encapsulate all current formats would require that you write individual image classes for each type of pixel format, for each type of image encoding. Using my pixel class, I only have to make a few specializations, and I can use the TPixel class for any image, accepting the type of component format as a template parameter.
Remember, I am doing a lot of software image manipulation, and the granularity here is necessary because when I''m writing my tri-linear interpolated image morphing code, I would rather see math performed on entire pixel objects with out worrying about the individual components. My image class has to be general enough to encapsulate any RGB(A) format, from using monochrome bits to GLfloats, and conversion is necessary in some cases, too. Based on all of the presented arguments, yours, mine, and all others here, I don''t think I''m all that crazy for using a pixel class.
Thank you for your interest, though, Kylotan.
Succinct. There is no reason not to use your pixel class.
C++ compilers are no more code bloater(asside from your exception problems with borland).
A small completly inlined class will be as fast as macros in release mode. In debug, you don''t care!
I have a ray tracer/radiosity that used small basic class for coloring (RGB, RGBA, LUMINANCE) and I build images from it
template
class Image
{
array of COLORTYPE;
}
Image supports operation like *, + , -. The implementation is really simple because each basic class also have those operations.
A friend of mine did the same thing for an RGB image but with macros.
Speed difference to do image operations on an 850Mhz?( in release mode of course)
0 - none - (somethimes his was a little faster, somethimes mine was a little faster)
the good thing is my code is easier to read and easy to modify and extend.
Oh well, I feel sorry for the people who looks at the Quake source and thinks it is the greatest thing on earth and it is how they should write their code.
C++ compilers are no more code bloater(asside from your exception problems with borland).
A small completly inlined class will be as fast as macros in release mode. In debug, you don''t care!
I have a ray tracer/radiosity that used small basic class for coloring (RGB, RGBA, LUMINANCE) and I build images from it
template
class Image
{
array of COLORTYPE;
}
Image supports operation like *, + , -. The implementation is really simple because each basic class also have those operations.
A friend of mine did the same thing for an RGB image but with macros.
Speed difference to do image operations on an 850Mhz?( in release mode of course)
0 - none - (somethimes his was a little faster, somethimes mine was a little faster)
the good thing is my code is easier to read and easy to modify and extend.
Oh well, I feel sorry for the people who looks at the Quake source and thinks it is the greatest thing on earth and it is how they should write their code.
Author
Mag:
It''s the command line option k.
Thing is, though the help docs say:
"Other options can be changed anywhere. The following options will only affect the compiler if they get changed between functions or object declarations:"
and include -k in there, putting
*makes a realization*
Disabling the stack frames option explicitily under the project options dialog does not remove it... Maybe it''s not the stack frames, mag...
Oh well, more research is necessary...
It''s the command line option k.
Thing is, though the help docs say:
"Other options can be changed anywhere. The following options will only affect the compiler if they get changed between functions or object declarations:"
and include -k in there, putting
#pragma option -k- *makes a realization*
Disabling the stack frames option explicitily under the project options dialog does not remove it... Maybe it''s not the stack frames, mag...
Oh well, more research is necessary...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
