I have a simple wrapper for an Mersenne twister random number generator. The purpose is to scale the number returned by the generator (between 0 and 1) to between argument defined limits (begin and end).
So my function is
inline float xlRandomFloat(float begin, float end) {return (begin+((end-begin)*genrand_real2()));}
I don't believe the implementation of genrand_real2() function is important, but if I am wrong it can be found here
The problem is the function does not return the translated result. The scaling (multiplying by (begin-end) seems to work correctly, but the addition of begin does not seem to be returned.
So if I call xlRandomFloat(5,10) - I get values between 0 and 5.
If I debug with GDB, and use the print function then it shows the correct result.
So then I tried separating things into lines to see what happens
inline float xlRandomFloat(float begin, float end) {
float ret;
ret=(((end-begin)*genrand_real2()));
ret+=begin;
return ret;};
When debugging, it jumped straight from the first line into the genrand_real2() function and skipped out every thing else entirely. That was really confusing so I thought it may have something to do with the inlining.
I moved the file from this .hpp file to the .cpp and removed the inline keyword and everything works correctly.
But why does this behavior occur, and how can I inline this function? Also, I am not sure if this is relevant, but often when I made changes to the sources, my Make compilation would say there is nothing to be done. Which is unusual since normally I expect make to pick up on changes in the sources and rebuild accordingly.
Any ideas.
Thanks
Zenna
Okay, several things at work here.
First, on the debugging, you describe what I'd think of as the more or less expected behavior, because when you inline a function, there's no generated code to go with the fromt matter of the function. So, the first statement there is
ret=(((end-begin)*genrand_real2()));
and the first step on that is to call genrand_real2(). If genrand_real2() is also inline, then you end up at the first statement in that, with no pause to catch your breath.
Second, make sure you're really running the code you think you are. Try making from a clean directory --some C++ compilers make precompiled pieces that they preserve to speed compilation. Make sure your inline definition has been completely removes or commented out from the header files. m
Thrd, make a very simple program with an inline and make sure it's behaving as you expect.
Your code is perfectly fine, there must be something wrong with the way you're compiling. Make sure your Makefile has the proper dependencies: the source files need to depend on the header files that they include. Tracking these dependencies is rarely done by hand, usually only for very small projects -- they are normally generated by a tool such as makedepend.
To see if inlining is causing the problem, just disable all optimizations by using the -O0 (dash capital-oh zero) option with GCC. Also make sure to enable debugging symbols with -g.
Related
I am building somewhat larger c++ code bases than I'm used to. I have a need for both good logging and debugging, at least to the console, and also speed.
Generally, I like to do something like this
// Some header file
bool DEBUG = true;
And then in some other file
if (DEBUG) cout << "Some debugging information" << endl;
The issue with this (among others) is that the branching lowers the speed of the final executable. In order to fix this, I'd have to go into the files at the end and remove all these, and then I couldn't use them again later without saving them to some other file and then putting them back in.
What is the most efficient solution to this quandry? Python decorators provide a nice approach that I'm not certain exists in CPP.
Thanks!
The classic way is to make that DEBUG not a variable, but a preprocessor macro. Then you can have two builds: one with the macro defined to 1, the other with it defined to 0 (or not defined at all, depending on how you plan to use it). Then you can either do #ifdef to completely remove the debug code from being seen by the compiler, or just put it into a regular if, the optimizer will take care of removing the branch with the constant conditional.
struct Foo{
Bar get(){
}
}
auto f = Foo();
f.get();
For example you decide that get was a very poor choice for a name but you have already used it in many different files and manually changing ever occurrence is very annoying.
You also can't really make a global substitution because other types may also have a method called get.
Is there anything for D to help refactor names for types, functions, variables etc?
Here's how I do it:
Change the name in the definition
Recompile
Go to the first error line reported and replace old with new
Goto 2
That's semi-manual, but I find it to be pretty easy and it goes quickly because the compiler error message will bring you right to where you need to be, and most editors can read those error messages well enough to dump you on the correct line, then it is a simple matter of telling it to repeat the last replacement again. (In my vim setup with my hotkeys, I hit F4 for next error message, then dot for repeat last change until it is done. Even a function with a hundred uses can be changed reliably* in a couple minutes.)
You could probably write a script that handles 90% of cases automatically too by just looking for ": Error: " in the compiler's output, extracting the file/line number, and running a plain text replace there. If the word shows up only once and outside a string literal, you can automatically replace it, and if not, ask the user to handle the remaining 10% of cases manually.
But I think it is easy enough to do with my editor hotkeys that I've never bothered trying to script it.
The one case this doesn't catch is if there's another function with the same name that might still compile. That should never happen if you do this change in isolation, because an ambiguous name wouldn't compile without it.
In that case, you could probably do a three-step compiler-assisted change:
Make sure your code compiles before. Then add #disable to the thing you want to rename.
Compile. Every place it complains about it being unusable for being disabled, do the find/replace.
Remove #disable and rename the definition. Recompile again to make sure there's nothing you missed like child classes (the compiler will then complain "method foo does not override any function" so they stand right out too.
So yeah, it isn't fully automated, but just changing it and having the compiler errors help find what's left is good enough for me.
Some limited refactoring support can be found in major IDE plugins like Mono-D or VisualD. I remember that Brian Schott had plans to add similar functionality to his dfix tool by adding dependency on dsymbol but it doesn't seem implemented yet.
Not, however, that all such options are indeed of a very limited robustness right now. This is because figuring out the fully qualified name of any given symbol is very complex task in D, one that requires full semantics analysis to be done 100% correctly. Think about local imports, templates, function overloading, mixins and how it all affects identifying the symbol.
In the long run it is quite certain that we need to wait before reference D compiler frontend becomes available as a library to implement such refactoring tool in clean and truly reliable way.
A good find all feature can be better than a bad refactoring which, as mentioned previously, requires semantic.
Personally I have a find all feature in Coedit which displays the context of a match and works on all the project sources.
It's fast to process the results.
I am running an atmospheric model, and need to compile an executable to convert some files. If I compile the code as supplied, it runs but it gets stuck and doesn't ever complete. It doesn't give an error or anything like that.
After doing some testing by adding print statements to see where it was getting stuck, I've found that the executable only runs if I compile the code with a print statement in one of the subroutines.
The piece of code in question is the one here. Specifically, the code fails to run unless I put a print statement somewhere in the get_bottom_top_dim subroutine.
Does anyone know why this might be? It doesn't matter what the print statement is (currently I'm using print*, '!'). but as soon as I remove it or comment it out, the code no longer works.
I'm assuming it must have something to do with my machine or compiler (ifort 12.1.0), but I'm stumped as to what the problem is!
This is an extended comment rather than an answer:
The situation you describe, inserting a print statement which apparently fixes a program, often arises when the underlying problem is due to either
a) an attempt to access an element outside the declared bounds of an array; or
b) a mismatch between dummy and actual arguments to some procedure.
Recompile your program with the compiler options to check interfaces at compile-time and to check array bounds at run-time.
Fortran has evolved a LOT since I last used it but here's how to go about solving your problem.
Think of some hypotheses that could explain the symptoms, e.g. the compiler is optimizing the subroutine down to a no-op when it has no print side effect. Or a compiler bug is translating this code into something empty or an infinite loop or crashing code. (What exactly do you mean by "fails to run"?) Or the Linker is failing to link in some needed code unless the subroutine explicitly calls print.
Or there's a bug in this subroutine and the print statement alters its symptoms e.g. by changing which data gets overwritten by an index-out-of-bounds bug.
Think of ways to test these hypotheses. You might already have observations adequate to rule out of some of them. You could decompile the object code to see if this subroutine is empty. Or step through it in a debugger. Or replace the print statement with a different side effect like logging to a file or to an in-memory text buffer.
Or turn on all optional runtime memory checks and compile time warnings. Or simplify the code until the problem goes away, then binary search on bringing back code until the problem recurs.
Do the most likely or easiest tests first. Rule out some hypotheses, and iterate.
I had a similar bug and I found that the problem was in the dependencies on the makefile.
This was what I had:
I set a variable with a value and the program stops.
I write a print command and it works.
I delete the print statement and continues to work.
I alter the variable value and stops.
The thing is, the variable value is set in a parameters.f90
The print statement is in a file H3.f90 that depends on parameters.f90 but it was not declared on the makefile.
After correcting:
h3.o: h3.f90 variables.f90 parameters.f90
$(FC) -c h3.f90
It all worked properly.
I have a function in my program that preforms a whole bunch of floating point math. It returns an array of values which is not currently being used in my program yet.
I want to test this piece of code for speed under maximum optimizations, however since the code isn't used, the compiler conveniently skips the function all together and I can't get a time on it.
How do force the compiler to run that section of code under maximum optimizations even though the result is not used (I want the computer to just give me a sense as to how fast the section runs).
I'm running Visual C++ 2008.
You could use SecureZeroMemory() to overwrite the result after is has been received from the function. You don't even need to overwrite the whole result, one array element will be enough, maybe you can even pass zero as "number of bytes", so that nothing is done by the function.
This will do the trick on Windows - SecureZeroMemory() is intended to never be optimized out by the compiler. Using it is pretty straightforward and it's rather fast.
I'm sure there are many compiler tricks, but the easiest way is to just make it look like you are using the value. In this case, just pass the returned array to some other function. The other function doesn't need to do anything, but that should be enough to convince the compiler you need the results.
If you find that your empty second function is being optimized out as well, then just stick it in a shared library (DLL) and it is impossible for the compiler to know how it is being used.
How you allocate the result can also change this. If you pass the original function a pointer, you could just pass it a heap pointer. Since that pointer may be used somewhere else it is highly unlikely the compiler could optimize away the code, as it has no idea if the results will be used or not.
You could also just legitimately use the data. It makes sense to verify the results in another function. If doing performance testing just put this verification part outside of the timed section. This is generally how I do such performance tests (make sure the result is checked/used).
This is what a test case is for. Write a test case in a separate binary (even just in the main() method) which sets a throwaway local variable to the result of the function. Time using your preferred method (e.g by capturing time(NULL) from immediately before and after the assignment and printing the time difference). You should have a decent idea of running time from that.
EDIT: time(NULL) is whole-second precision = bad and evil. Use clock(), as shown here, for the most accurate precision in the C/C++ standard library.
if you are using visual studio the code down here would work, but idon't know about any other solutions for gcc
#pragma optimize( "", off )
.
.
.
#pragma optimize( "", on )
I have a huge template file and only few functions are used, and I want to isolate that part for test and comment the other half. How can i find what's the best way to do this ?
How can I do this on a Windows system and the template file is .hxx ?
I like Mohammad's answer. Oops... he removed it - but basically - use a tool like nm - I don't know a windows equivalent but there's sure to be one - to query the objects for instantations. While your templates may be in a .hxx, you can only meaningfully talk about the subset of methods instantiated by some body of client code. You may need to do this analysis with inlining disabled, to ensure the function bodies are actually instantiated in a tangible form in the object files.
In the less likely event that you might have instantiated stuff because some code handles cases that you know the data doesn't - and won't evolve to - use, then you may prefer automated run-time coverage analysis. Many compilers (e.g. GCC's g++ -ftest-coverage) and tools (e.g. purecov) provide this.
How about commenting out the whole file, then uncommenting individual methods when the linker complains, until the program can be compiled ?
By the way, if you are using Visual Studio, commenting the whole file is just a matter of using the following key shortcuts : Ctrl+A, then Ctrl+K+C. You can uncomment selected lines using Ctrl+K+U.