Search Results

Search found 9 results on 1 pages for 'stingraysc'.

Page 1/1 | 1 

• Controlling FPU behavior in an OpenMP program?

  - by STingRaySC

  I have a large C++ program that modifies the FPU control word (using _controlfp()). It unmasks some FPU exceptions and installs a SEHTranslator to produce typed C++ exceptions. I am using VC++ 9.0. I would like to use OpenMP (v.2.0) to parallelize some of our computational loops. I've already successfully applied it to one, but the numerical results are slightly different (though I understand it could also be due to calculations being performed in a different order). I'm assuming this is because the FPU state is thread-specific. Is there some way to have the OpenMP threads inherit that state from the master thread? Or is there some way to specify using OpenMP that new threads execute a particular function that sets up the correct state? What is the idiomatic way to deal with this situation?

  Read the article

• Strange C++ performance difference?

  - by STingRaySC

  I just stumbled upon a change that seems to have counterintuitive performance ramifications. Can anyone provide a possible explanation for this behavior? Original code: for (int i = 0; i < ct; ++i) { // do some stuff... int iFreq = getFreq(i); double dFreq = iFreq; if (iFreq != 0) { // do some stuff with iFreq... // do some calculations with dFreq... } } While cleaning up this code during a "performance pass," I decided to move the definition of dFreq inside the if block, as it was only used inside the if. There are several calculations involving dFreq so I didn't eliminate it entirely as it does save the cost of multiple run-time conversions from int to double. I expected no performance difference, or if any at all, a negligible improvement. However, the perfomance decreased by nearly 10%. I have measured this many times, and this is indeed the only change I've made. The code snippet shown above executes inside a couple other loops. I get very consistent timings across runs and can definitely confirm that the change I'm describing decreases performance by ~10%. I would expect performance to increase because the int to double conversion would only occur when iFreq != 0. Chnaged code: for (int i = 0; i < ct; ++i) { // do some stuff... int iFreq = getFreq(i); if (iFreq != 0) { // do some stuff with iFreq... double dFreq = iFreq; // do some stuff with dFreq... } } Can anyone explain this? I am using VC++ 9.0 with /O2. I just want to understand what I'm not accounting for here.

  Read the article

• deleted......................

  - by STingRaySC

  deleted.............................

  Read the article

• deleted........................

  - by STingRaySC

  [deleted]...........................

  Read the article

• C/C++ Control Structure Limitations?

  - by STingRaySC

  I have heard of a limitation in VC++ (not sure which version) on the number of nested if statements (somewhere in the ballpark of 300). The code was of the form: if (a) ... else if (b) ... else if (c) ... ... I was surprised to find out there is a limit to this sort of thing, and that the limit is so small. I'm not looking for comments about coding practice and why to avoid this sort of thing altogether. Here's a list of things that I'd imagine could have some limitation: Number of functions in a scope (global, class, or namespace). Number of expressions in a single statement (e.g., compound conditionals). Number of cases in a switch. Number of parameters to a function. Number of classes in a single hierarchy (either inheritance or containment). What other control structures/language features have limits such as this? Do the language standards say anything about these limits (perhaps minimum requirements for an implementation)? Has anyone run into a particular language limitation like this with a particular compiler/implementation? EDIT: Please note that the above form of if statements is indeed "nested." It is equivalent to: if (a) { //... } else { if (b) { //... } else { if (c) { //... } else { //... } } }

  Read the article

• VS 2008 C++ build output?

  - by STingRaySC

  Why when I watch the build output from a VC++ project in VS do I see: 1Compiling... 1a.cpp 1b.cpp 1c.cpp 1d.cpp 1e.cpp [etc...] 1Generating code... 1x.cpp 1y.cpp [etc...] The output looks as though several compilation units are being handled before any code is generated. Is this really going on? I'm trying to improve build times, and by using pre-compiled headers, I've gotten great speedups for each ".cpp" file, but there is a relatively long pause during the "Generating Code..." message. I do not have "Whole Program Optimization" nor "Link Time Code Generation" turned on. If this is the case, then why? Why doesn't VC++ compile each ".cpp" individually (which would include the code generation phase)? If this isn't just an illusion of the output, is there cross-compilation-unit optimization potentially going on here? There don't appear to be any compiler options to control that behavior (I know about WPO and LTCG, as mentioned above). EDIT: The build log just shows the ".obj" files in the output directory, one per line. There is no indication of "Compiling..." vs. "Generating code..." steps. EDIT: I have confirmed that this behavior has nothing to do with the "maximum number of parallel project builds" setting in Tools - Options - Projects and Solutions - Build and Run. Nor is it related to the MSBuild project build output verbosity setting. Indeed if I cancel the build before the "Generating code..." step, the ".obj" files will not exist for the most recent set of "compiled" files. E.g., if I cancel the build during "c.cpp" above, I will see only "a.obj" and "b.obj".

  Read the article

• Why and when should one call _fpreset( )?

  - by STingRaySC

  The only documentation I can find (on MSDN or otherwise) is that a call to _fpreset() "resets the floating-point package." What is the "floating point package?" Does this also clear the FPU status word? I see documentation that says to call _fpreset() when recovering from a SIGFPE, but doesn't _clearfp() do this as well? Do I need to call both? I am working on an application that unmasks some FP exceptions (using _controlfp()). When I want to reset the FPU to the default state (say, when calling to .NET code), should I just call _clearfp(), _fpreset(), or both. This is performance critical code, so I don't want to call both if I don't have to...

  Read the article

• No "redefinition of default parameter error" for class template member function?

  - by STingRaySC

  Why does the following give no compilation error?: // T.h template<class T> class X { public: void foo(int a = 42); }; // Main.cpp #include "T.h" #include <iostream> template<class T> void X<T>::foo(int a = 13) { std::cout << a << std::endl; } int main() { X<int> x; x.foo(); // prints 42 } It seems as though the 13 is just silently ignored by the compiler. Why is this? The cooky thing is that if the template declaration is in Main.cpp instead of a header file, I do indeed get the default parameter redefinition error. Now I know the compiler will complain about this if it were just an ordinary (non-template) function. What does the standard have to say about default parameters in class template member functions or function templates?

  Read the article

• When does invoking a member function on a null instance result in undefined behavior?

  - by GMan

  This question arose in the comments of a now-deleted answer to this other question. Our question was asked in the comments by STingRaySC as: Where exactly do we invoke UB? Is it calling a member function through an invalid pointer? Or is it calling a member function that accesses member data through an invalid pointer? With the answer deleted I figured we might as well make it it's own question. Consider the following code: #include <iostream> struct foo { void bar(void) { std::cout << "gman was here" << std::endl; } void baz(void) { x = 5; } int x; }; int main(void) { foo* f = 0; f->bar(); // (a) f->baz(); // (b) } We expect (b) to crash, because there is no corresponding member x for the null pointer. In practice, (a) doesn't crash because the this pointer is never used. Because (b) dereferences the this pointer (this->x = 5;), and this is null, the program enters undefined behavior. Does (a) result in undefined behavior? What about if both functions are static?

  Read the article

1