I am having little success forcing g++ to generate vector (aka omp simd) calls to virtual functions. Consider the base class
class vecclass_v {
public:
#pragma omp declare simd simdlen(4)
virtual double vecf(double v1, double v2) = 0;
}
and a derived class that implements the (should be) vectorized vecf
class vecclass : public vecclass_v {
public:
#pragma omp declare simd simdlen(4)
double vecf(double v1, double v2);
};
The implementation is in a cxx file. Looking at the object files I can see that g++ correctly generates instances of vectorized functions for the derived class. But calling the virtual function is not resolved to a vectorized call. It uses the scalar member instance instead, e.g., in a usecase like this one
vecclass_v *ob = [get an instance of vecclass somewhere]
ob->vecf(a, b); // this should be vectorized, but is not
The Intel compiler does support vectorized virtual functions (https://software.intel.com/en-us/articles/virtual-vector-function-supported-in-intel-c-compiler-170). Does g++ support this, but I just can't use it, or is this not implemented yet?
Related
Is there a way to unroll a loop in GCC based on compile-time (e.g., template) parameter?
The following does not compile, unless I replace unroll(N) with a concrete integer like unroll(8)
template<int N>
void fun ()
{
#pragma GCC unroll(N)
for (...)
// body
}
I am wrapping some c++ library code to create a pybind11 module. I adopt the approach described here:
https://github.com/pybind/cmake_example
After building the library, it will be imported in Python using something like:
import cmake_example as m
In order to be used, the library needs to be initialized. During initialization, the code reads some environment variables, sets some internal variables, and prints some stuff, etcetera. Also, there is finalization.
How to ensure that initialization and finalization code is always run? One approach would be to do something like
import cmake_example as m
m.init()
#use module
m.finalize()
However, to make the library easier to use, I would consider handle this on the c++ side: By adding stuff to the c++ code to ensure that init and cleanup are called automatically respectively when the module is imported and when the python script/session ends.
I could imagine that this could be accomplished by adding a static variable of custom type, and to call the initialization code when the custom type is initialized, and the cleanup code when it finalizes. Something like:
#include <pybind11/pybind11.h>
#include <iostream>
class Module
{
public:
Module()
{
std::cout << "initializing";
//code initialization
}
~Module()
{
std::cout << "finalizing";
//finalize
}
};
static Module module;
namespace py = pybind11;
PYBIND11_MODULE(pybind_example, m) {
//Create all the bindings.
}
This seems to work when I test it for my current setup (windows, python 2.9)? Will it suddenly break for other configurations? Are there alternatives that are recommended over this?
Your approach works, but it's pretty brittle and you might run into the "static initialization order fiasco"
A more robust way would be to initialize a static variable inside the pybind scope:
PYBIND11_MODULE(pybind_example, m) {
static Module module;
// Create bindings
}
While working in the system c program I missed out the public keyword before constructor, but the program works fine.
But in C++, its throwing an error
SystemC requires that first parameter to module constructor should be sc_module_name. Other than that, there is nothing special. SystemC macros SC_MODULE and SC_CTOR just save you some time, but you are not required to use them.
SC_MODULE( dut ) {
SC_CTOR(dut) { }
};
Is equivalent to:
struct dut : sc_core::sc_module {
typedef dut SC_CURRENT_USER_MODULE;
dut(::sc_core::sc_module_name) {}
};
Please note that struct members are public by-default, and class members are private by default. If you use class instead of struct, you will need to make them public by adding public: explicitly:
class dut : public sc_core::sc_module {
typedef dut SC_CURRENT_USER_MODULE;
public:
dut(::sc_core::sc_module_name) {}
};
I have created a new managed, reference class in C++ cli. And now I want to overload equality of objects of this class.
public ref class DerivedFromObject {
virtual bool Equals(Object^ obj) override;
virtual int GetHashCode() override;
static bool operator!= (const DerivedFromObject%, const DerivedFromObject%);
static bool operator== (const DerivedFromObject%, const DerivedFromObject%);
}
As far as I know from C#, operator!= calls operator==, that calls Equals, which refers to GetHashCode.
bool DerivedFromObject::operator==(const DerivedFromObject % a, const DerivedFromObject % b)
{
a.Equals((Object^)%b); // Error
}
In the snippet above, Equals and GetHashCode cannot be called on a const object, that's why I cannot call Equals from operator==.
How can I mark method that doesn't change the object in C++ cli? Or What the most appropriative way to define equality chain?
There's two things here:
.Net doesn't really have the concept of const in the way that C++ does. C++/CLI will enforce the rules that C++ has, but since .Net doesn't use it, no library methods are declared const, so you'll have problems calling just about any method. Rather than being explicitly declared like in C++, it's just by convention that methods like equals don't modify their parameters.
Since you used const%, I think you were trying to parallel the C++ convention of passing const& parameters. % is more similar in usage to ** double pointer than to &: You pass things parameters as % (or ^% for reference types) when the method can assign a value to the parameter, and it should be available to the calling method.
Here's how I would implement this:
public ref class DerivedFromObject : IEquatable<DerivedFromObject> {
virtual bool Equals(DerivedFromObject^ other);
virtual bool Equals(Object^ obj) override;
virtual int GetHashCode() override;
static bool operator!= (DerivedFromObject^, DerivedFromObject^);
static bool operator== (DerivedFromObject^, DerivedFromObject^);
}
One other thing you said:
...Equals, which refers to GetHashCode.
Be careful here, because it is possible for unequal objects to have the same hash code.
GetHashCode will need to evaluate everything, and then if the hash codes are equal, then Equals need to evaluate everything again to be sure they're actually equal. It'll probably be more efficient to not look at the hash code, just compare the objects field by field, and bail out as soon as they're not equal.
I have to use dlopen() and access functions from shared object in my code. Do I need to include headers of corresponding functions of shared object ?
Because of the way dlopen() and dlsym() operate, I don't see how that would accomplish anything. Very roughly speaking, dlopen() copies the library binary into your program space and adds the addresses of its exported symbols (i.e. global functions & variables) to your program's symbol table.
Because the library was not linked to your program at compile-time, there's no way your code could possibly know the instruction addresses of these new functions tacked on at run-time. The only way to access a run-time dynamically linked symbol is via a pointer obtained from dlsym().
You have to create a function pointer for each and every library definition that you want to use. If you want to call them like regular functions, in C-language you can manually typedef type definitions for the function pointers, specifying their parameters and return values, then you can call the pointers just like regular functions. But note that you have to define all of these manually. Including the library header doesn't help.
In C++ I think there are issues with storing dlsym() output in a typedef'd pointer due to stricter standards, but this should work in C:
addlib.c (libaddlib.dylib):
int add(int x, int y) {
return x+y;
}
myprogram.c:
#include <stdio.h>
#include <dlfcn.h>
typedef int (*add_t)(int, int);
int main() {
void *lib_handle;
add_t add; // call this anything you want...it's a pointer, it doesn't care
lib_handle = dlopen("libaddlib.dylib", RTLD_NOW);
if (lib_handle == NULL) {
// error handling
}
add = (add_t)dlsym(lib_handle, "add");
if (add == NULL) {
// error handling
}
printf("Sum is %d\n", add(17, 23));
dlclose(lib_handle); // remove library from address space
return 0;
}
(Update: I compiled the dylib and myprogram...it works as expected.)