OpenMP with Open Beagle

[Jeannie]

Hi Christian, 

It is possible to use OpenMP with Open Beagle for MOGP? I can see the open mp directives in the OB code and note the existence of an OpenMP component also.

However, I am not sure how it should be implemented. Do I need to add this component to my OB System object?  The documentation contains some detail about

HPC also. 

I am using OB 4 alpha, have the correct openMP library installed, and am compiling with gcc -fopenmp -03.  My system is an i7 quad core.

The MOGP is working fine sequentially, but as the data set I am using is very large - the overhead is making execution very slow. Hence I would like to try to use

some parallel features of OB.

many thanks,

jeannie

[Christian Gagné]

Dear Jeannie,

To activate OpenMP extension, you need first to activate it when compiling the code. This is done through the CMake option BEAGLE_OMP_MODE, which can be set either to "STATIC" and "DYNAMIC" for OpenMP to be activated. STATIC mode allow to have reproducible results when reusing the same RNG seed, but with possibly a smaller speedup. DYNAMIC mode does not allow to have reproducible results.

Indeed, for this to work, you need to add the OpenMP component in the system in your main function, which will store all OpenMP variables required for parallel execution.

Best speedup you can expect by using OpenMP is for evaluating fitness of individuals in parallel, on a multicore machine. For the crossover, mutation, and selection operators, this speedup should be small, as far as fitness evaluation takes most of the CPU time.

Best,

Christian

> --
>
>
>

--
Christian Gagné
http://vision.gel.ulaval.ca/~cgagne

[Jeannie]

Hi Christian,

Thanks for the reply. I have not used CMake myself, rather I usually use gnu make. Does the BEAGLE_OMP_MODE option work in the same way with make?

thanks again,

jeannie

[Christian Gagné]

Hi again Jeannie,

CMake can output to many build systems, including make. Setting the BEAGLE_OMP_MODE value to STATIC and DYNAMIC does more than setting the -fopenmp flag to GCC. There are some C preprocessor flags and compilier options set, and the classes OpenMP and RandomizerMulti are compiled with the main library. I would advice you to look at this snippet of CMake configuration below for the BEAGLE_OMP_MODE option in the CMakeList.txt file of Open BEAGLE 4.0-alpha2 to figure out what is done (the syntax is quite direct, you should be able to understand what is happenning).

Best,

Christian


if(OPENMP_FOUND)
message(STATUS "++ OpenMP found")

if(NOT DEFINED BEAGLE_OMP_MODE)
message(STATUS "++ If you want to enable OpenMP, set BEAGLE_OMP_MODE to STATIC or DYNAMIC, depending in which mode scheduler should work.")
set(BEAGLE_OMP_MODE "NONE" CACHE STRING "OpenMP scheduler modes : NONE (do not use OpenMP at all), STATIC (reproducible results), DYNAMIC (non-reproducible results)")
endif(NOT DEFINED BEAGLE_OMP_MODE)

string(TOUPPER ${BEAGLE_OMP_MODE} BEAGLE_OMP_MODE)

if(BEAGLE_OMP_MODE MATCHES "NONE")
message(STATUS "++ OpenMP is not enabled, set BEAGLE_OMP_MODE to STATIC | DYNAMIC to enable it.")
set(BEAGLE_USE_OMP_R False)
set(BEAGLE_USE_OMP_NR False)
elseif(BEAGLE_OMP_MODE MATCHES "STATIC")
message(STATUS "++ OpenMP enabled, scheduler set to static mode.")
set(BEAGLE_USE_OMP_R True)
set(BEAGLE_USE_OMP_NR False)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
elseif(BEAGLE_OMP_MODE MATCHES "DYNAMIC")
message(STATUS "++ OpenMP enabled, scheduler set to dynamic mode.")
set(BEAGLE_USE_OMP_NR True)
set(BEAGLE_USE_OMP_R False)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
else(BEAGLE_OMP_MODE MATCHES "NONE")
message(STATUS "++ Invalid value for BEAGLE_OMP_MODE : NONE | STATIC | DYNAMIC expected, but found ${BEAGLE_OMP_MODE}; OpenMP is disabled.")
set(BEAGLE_OMP_MODE "NONE" CACHE STRING "OpenMP scheduler modes : NONE (do not use OpenMP at all), STATIC (reproducible results), DYNAMIC (non-reproducible results)")
set(BEAGLE_USE_OMP_R False)
set(BEAGLE_USE_OMP_NR False)
endif(BEAGLE_OMP_MODE MATCHES "NONE")

if(NOT BEAGLE_OMP_MODE MATCHES "NONE")
set(BEAGLE_HAVE_OPENMP 1)

if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
message(STATUS "++ Compiling with GNU, parallel version of STL algorithms will be used if they are available.")
execute_process(COMMAND gcc -dumpversion OUTPUT_VARIABLE CMAKE_CXX_COMPILER_VERSION)

if(CMAKE_CXX_COMPILER_VERSION MATCHES "4?\\.[3-9]?\\.[0-9]")
message(STATUS "GCC ${CMAKE_CXX_COMPILER_VERSION} found, enabling parallel STL")

set(CMAKE_REQUIRED_FLAGS "-L${PACC_LIB_FOUND_DIR} -I${PACC_INCLUDE_FOUND_DIR} -lpacc -fopenmp -D_GLIBCXX_PARALLEL")
message(STATUS "++ Check if PACC has been compiled with parallel STL...")
PerformTest(PACC_HAVE_PARALLEL_STL)
if(NOT PACC_HAVE_PARALLEL_STL)
message("!! Warning : your PACC library has not been compiled with parallel version of STL, forced to disable parallel STL for beagle too...")
else(NOT PACC_HAVE_PARALLEL_STL)
message(STATUS "++ PACC parallel STL ok...")
add_definitions(-D_GLIBCXX_PARALLEL)
endif(NOT PACC_HAVE_PARALLEL_STL)
set(CMAKE_REQUIRED_FLAGS) # Unset modified CMake variables
else(CMAKE_CXX_COMPILER_VERSION MATCHES "4?\\.[3-9]?\\.[0-9]")
message(STATUS "Parallel STL requires GCC >= 4.3, you are using ${CMAKE_CXX_COMPILER_VERSION}")
endif(CMAKE_CXX_COMPILER_VERSION MATCHES "4?\\.[3-9]?\\.[0-9]")
endif(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
endif(NOT BEAGLE_OMP_MODE MATCHES "NONE")

mark_as_advanced(BEAGLE_USE_OMP_R BEAGLE_USE_OMP_NR)

else(OPENMP_FOUND)
message(STATUS "++ OpenMP not found")
endif(OPENMP_FOUND)

if(NOT BEAGLE_USE_OMP_NR AND NOT BEAGLE_USE_OMP_R)
set(BEAGLE_OPENMP_FILES "OpenMP.cpp RandomizerMulti.cpp")
else(NOT BEAGLE_USE_OMP_NR AND NOT BEAGLE_USE_OMP_R)
set(BEAGLE_OPENMP_FILES "null")
endif(NOT BEAGLE_USE_OMP_NR AND NOT BEAGLE_USE_OMP_R)

[Jeannie]

Hi again Christian,

Ok, I have rebuilt the libraries with the BEAGLE_OMP_MODE option set to STATIC. It was not necessary to add an OpenMP component to the system as the system tells me that there is already one configured. At the moment I am getting a seg fault in the initialisation  on the Randomizer call.  Is there some step that I have missed?

j

<Log>Current date and time: 14:52:50 08 Jan 2013</Log>

    <Log>Evolving generation 0</Log>

    <Log>Applying bootstrap operators to the 1st deme</Log>

Program received signal SIGSEGV, Segmentation fault.

MTRand::randInt (this=0x6ae320) at /usr/local/include/PACC/Util/MTRand.hpp:208

(gdb) up

#1  0x0000000000479218 in randInt (n=<optimized out>, this=0x6ae320) at /usr/local/include/PACC/Util/MTRand.hpp:229

(gdb) up

#2  Beagle::Randomizer::rollInteger (this=0x6ae300, inLower=1, inUpper=<optimized out>) at /usr/local/include/beagle/Randomizer.hpp:115

(gdb) up

#3  0x00007ffff753e4a7 in Beagle::GP::InitializationOp::initIndividual (this=0x6c7c20, outIndividual=..., ioContext=...) at /home/jeannief/ShareHost/OpenBEAGLE-4.0.0-alpha2-Source/src/beagle/GP/InitializationOp.cpp:186

(gdb) 

On Monday, 7 January 2013 21:59:17 UTC, Jeannie wrote:

[Jeannie]

Hi,

I think I need to recompile the PACC with the parallel option?

j

On Monday, 7 January 2013 21:59:17 UTC, Jeannie wrote:

[Christian Gagné]

Hi Jeannie,

It looks like there is something wrong with the compilation and/or the preprocessor flags.

Recompiloing PACC with the parallel option might help.

Be sure that the OB librairies are compiled with the same options than those you are using for your program.

Check also in the beagle/config.hpp tht the BEAGLE_HAVE_OPENMP and BEAGLE_USE_OMP_R (or BEAGLE_USE_OMP_NR, if your are using the dynamic version) are defined to 1.

Also, check whether you compiled the libraries with the parallel STL version activated (preprocessor flag _GLIBCXX_PARALLEL set). This need to be set for compiling all PACC, OB libraries and your program. Alternatively, you can disable for all (but do not mix it).

Hope this help,

Christian

[Jeannie]

Hi again Christian,

Thank you for all your help on this - I did not have the preprocessor flag set in my local Makefile. The system now running with OpenMP  - after a fashion.  

At the moment there are seg faults occurring on STL vector interactions- particularly on resize() - from what I have read this seems to be due to the fact that these STL methods invoke malloc() under the hood and this is likely to cause thread contention issues.   There is a lot going on in my EvaluationOp - so perhaps the functionality that I have implemented is not best suited to parallelism.

thanks again,

jeannie

On Monday, 7 January 2013 21:59:17 UTC, Jeannie wrote:

[Christian Gagné]

Hi Jeannie,

That's a possibility. Your evaluation method should indeed be thread-safe. Therefore, if you are sharing some date, you need to be sure that you are making only read access to it during the evaluation, otherwise you will need to tag critical sections using OpenMP directives. That can be quite complex, as even a assigning an Open BEAGLE smart pointer can be an issue, as it includes a write in memory (increment/decrement smart pointer's counter).

Christian

[Jeannie]

Hi AGAIN!

Just to let you know that all is now working well.  It was just a matter of putting #pragma omp critical around the critical regions to avoid problems with vector access.

all the best,

jeannie

On Monday, 7 January 2013 21:59:17 UTC, Jeannie wrote:

[Marc Segond]

Hi Jeannie.
Where exactly did you put them? I am trying to make it work, But the best I can do is having the evolution stop at generation 0 RUN FAILED (exit value 1, total time: 1s).
I am working on the symreg example, just trying to put an omp parallel for on the evaluation loop...

What did I do wrong?

Best

Marc

[Jeannie.Fitzgerald]

Hi Marc,

Have you put the correct flags in your Makefile to ensure that your own sources are compiled
with OpenMP? Also, is your Open Beagle compiled for Open MP?

There are a lot of different options for executing code sections/lines. If you have (say) 8 threads, then one of these is master and you can specify that certain lines of code are executed only by the master, or only by the first thread that arrives at that point, that they all have to wait for each other at certain points, or that certain parts of code are "critical" ie represent a critical sections - possible changing data values or i/o of some sort. You will find the syntax and explanation for all of these in OpenMP documentation on the web.

all the best,

jeannie

--

---
You received this message because you are subscribed to the Google Groups "openbeagle-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openbeagle-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Marc Segond]

Hi Jeannie!
Thanks for your answer.
Yes, my code is compiled with the openMP flag, and I recompiled the OB
library for openMP.
When I but all the initialization code between critical, it works, but
then, it is when I try to let the parallelization do its job that it
gets worse.
The thing is that I don't know how openMP is included in Beagle. Does it
use it to evaluate the indiv in parallel?
This would mean that I just have to turn on openMP and put some oprtions
of code into critical, but i would not have to put parallel directives
myself?

Best

Marc

On 02/25/2013 04:24 PM, Jeannie.Fitzgerald wrote:
> Hi Marc,
>
> Have you put the correct flags in your Makefile to ensure that your own sources are compiled
> with OpenMP? Also, is your Open Beagle compiled for Open MP?
>
> There are a lot of different options for executing code sections/lines. If you have (say) 8 threads, then one of these is master and you can specify that certain lines of code are executed only by the master, or only by the first thread that arrives at that point, that they all have to wait for each other at certain points, or that certain parts of code are "critical" ie represent a critical sections - possible changing data values or i/o of some sort. You will find the syntax and explanation for all of these in OpenMP documentation on the web.
>
> all the best,
>
> jeannie
>
>
>
> -----Original Message-----
> From: openbeag...@googlegroups.com on behalf of Marc Segond
> Sent: Mon 25/02/2013 15:05
> To: openbeag...@googlegroups.com
> Subject: [openbeagle-users] Re: OpenMP with Open Beagle
>
> Hi Jeannie.
> Where exactly did you put them? I am trying to make it work, But the best I
> can do is having the evolution stop at generation 0 RUN FAILED (exit value
> 1, total time: 1s).
> I am working on the symreg example, just trying to put an omp parallel for
> on the evaluation loop...
>
> What did I do wrong?
>
> Best
>
> Marc
>

> Le mercredi 9 janvier 2013 13:19:50 UTC+1, Jeannie a �crit :

[Jeannie.Fitzgerald]

Hi Marc,

I think you would need to verify this with Christian:
But it seems to me that currently all of the available threads
are running within each evaluation so you would need to make
all of your code thread safe. However, if you were to re define
the invocation of the "evaluate" as a critical section you may
be able to achieve the type of task parallelism that you want. To do
this might require a change to the Open Beagle source or else
for you to inherit from the default evolver component.

Christian is really the best person to advise you as he has expert
knowledge of the system.

> Le mercredi 9 janvier 2013 13:19:50 UTC+1, Jeannie a écrit :
>> Hi AGAIN!
>>
>> Just to let you know that all is now working well. It was just a matter
>> of putting #pragma omp critical around the critical regions to avoid
>> problems with vector access.
>>
>> all the best,
>>
>> jeannie
>>
>> On Monday, 7 January 2013 21:59:17 UTC, Jeannie wrote:
>>> Hi Christian,
>>>
>>> It is possible to use OpenMP with Open Beagle for MOGP? I can see the
>>> open mp directives in the OB code and note the existence of an OpenMP
>>> component also.
>>> However, I am not sure how it should be implemented. Do I need to add
>>> this component to my OB System object? The documentation contains some
>>> detail about
>>> HPC also.
>>>
>>> I am using OB 4 alpha, have the correct openMP library installed, and am
>>> compiling with gcc -fopenmp -03. My system is an i7 quad core.
>>> The MOGP is working fine sequentially, but as the data set I am using is
>>> very large - the overhead is making execution very slow. Hence I would like
>>> to try to use
>>> some parallel features of OB.
>>>
>>> many thanks,
>>>
>>> jeannie
>>>

[Marc Segond]

Hi OpenBeagle users.
I come again with a problem…
As the title says, I cannot manage to compile openBeagle4 with openMP: the CMake gives me this:

-- Try OpenMP C flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [/openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-Qopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [ ]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-xopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [+Oopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-qsmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-mp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [/openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-Qopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [ ]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-xopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [+Oopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-qsmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-mp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- ++ OpenMP not found

I have gcc4.7 installed using MacPorts. The result was the same with the classical 4.2.

Any Mac users with a solution?

Thanks!

Regards

--
Marc

[Christian Gagné]

Hi Marc and Jeannie,

Open MP is implemented for doing several things in parallel in Open BEAGLE. For instance, it can evaluates individual in parallel, but it can also parallelise crossover and mutation operations.

One tricky thing with Open MP and Open BEAGLE is that the random number generator needed to be set into critical sections. Given that the generator is a central element of an evolutionary algorithm, locking it each time it is called lead to important inefficiency and so bas speedup. We thus decided to provide a special random number generator, called RandomizerMulti, which in fact consists in one random number generator per thread. This made the code quite efficient. However, it requires to set up the System with the RandomizerMulti component, instead of the Randomizer one.

Overall, I would advice you to make the OpenMP stuffs to work on a regular Open BEAGLE example, to be sure you have it right. Then, you can consider to make it works for your problem.

Christian

> <winmail.dat>

[Marc Segond]

Hi Christian,
I've taken the symbreg sources and just compiled all with openmp, then
changed the random generator in the config file. Now I don't have a
runtime error from glibc but it still doesn't work: the evolution simply
exist before evaluating the 1st gen with an error, no hints about what
goes wrong.

<?xml version="1.0" encoding="ISO-8859-1"?>
<Beagle version="4.0.0-alpha2">
<Logger>
<Log>Open BEAGLE, version 4.0.0-alpha2</Log>
<Log>Setting console log level 2</Log>
<Log>Setting file log level 3</Log>
<Log>Logging to file 'beagle.log'</Log>
<Log>Reading file 'beagle.conf' for evolver configuration</Log>
<Log>Reading file 'beagle.conf' for system configuration</Log>
<Log>Randomizer (0) seed used: 10188896966866712472</Log>
<Log>Randomizer (1) seed used: 2576770236625160822</Log>
<Log>Starting an evolution</Log>
<Log>Current date and time: 10:27:44 26 Feb 2013</Log>

<Log>Evolving generation 0</Log>

RUN FAILED (exit value 1, total time: 274ms)


Is there anything to do in the symbreg code, like putting some things in
#pragma omp critical? Thinking about it, I cannot think about anything,
as basically the evaluation has to be parallelized, right?

Regards

Marc

>>> Le mercredi 9 janvier 2013 13:19:50 UTC+1, Jeannie a �crit :

[Marc Segond]

Dear all,
again a point about openMP: in the symbreg example, evolution fails when
the code reaches this line: setValue("X", lX, ioContext);

Here is the complete code of the symbreg (which I guess you all know...I
commented the lines after setValue("X", lX, ioContext); just to test).

Fitness::Handle SymbRegEvalOp::evaluate(GP::Individual& inIndividual,
GP::Context& ioContext)
{
//#pragma omp critical
// {
double lSquareError = 0.;
for(unsigned int i=0; i<mDataSet->size(); i++) {
Beagle_AssertM((*mDataSet)[i].second.size() == 1);
const Double lX((*mDataSet)[i].second[0]);
*setValue("X", lX, ioContext);*
// const Double lY((*mDataSet)[i].first);
// Double lResult;
// inIndividual.run(lResult, ioContext);
// const double lError = lY-lResult;
// lSquareError += (lError*lError);
}
const double lMSE = lSquareError / mDataSet->size();
const double lRMSE = sqrt(lMSE);
const double lFitness = 1. / (1. + lRMSE);
return new FitnessSimple(lFitness);
//}
}

Seems that manipulating the ioContext is the problem. As far as my
understanding goes, there should be as many ioContexts as evaluation
threads for the individuals, right? Is this the case? Unless, we would
have problems with only one shared ioContext for like 8 eval threads
modifying at the same time the "X" value. Another way of thinking would
be: the X value is the out of the parallelization, once per example for
a shared ioContext, and then the individuals are evaluated in parallel
by in a synchronous way, but looking at the code architecture, I don't
think this is the case, right?

Sorry for my poor understanding of openBeagle.

Cheers

Marc

On 02/25/2013 10:53 PM, Christian Gagn� wrote:

>>> Le mercredi 9 janvier 2013 13:19:50 UTC+1, Jeannie a �crit :

[Christian Gagné]

Hi Mark,

I think you put the finger on the problem. Indeed, calling the setValue function has important side-effects that are not compatible with a multithreaded fitness evaluation with OpenMP. For instance, calling the setValue function will change the value of the given GP primitive in the primitive set. That's correct to change the value of a variable for the different test cases of the fitness evaluation function, but making this in parallel inevitably leads to memory corruption, as the primitive set is shared among all GP trees. Moreover, blocking it in a critical OpenMP section is not a good fix, as it would make the fitness evaluation invalid, as a given thread may change the value during the evaluation of trees by other threads. Finally, making the whole fitness evaluation function as a critical block will simply disable all parallelism.

However, there is a workaround for making use of parallel fitness evaluation with GP. The approach is to make use of vectorial execution of GP trees. That means that instead of running the GP trees for each test case, and changing the value between each of these runs, the trees will be executed for all test cases at once. That is attained by making use of an array of real values (type DoubleArray) instead of scalar real values (Double) as data processed by the primitives. The primitives for symbolic regression should also be able to process DoubleArray instead of Double -- the templates of arithmetic GP primitives are supposed to handle this type well. Each element of the array will be a test case, processed much like in a vectorial processor (à la Matlab, if you prefer). Moreover, you can expect significant gains in terms of computing efficiency, as it will require one run of the GP trees, instead of as much runs as there is test cases. That's something I discussed with Jeannie some time ago on the old mailing list on Yahoogroups.

http://tech.groups.yahoo.com/group/openbeagle/message/1563

Best,

Christian

Christian Gagné
http://vision.gel.ulaval.ca/~cgagne

[Christian Gagné]

Hi Mark,

I made the test, and CMake was able to enable OpenMP on Open BEAGLE with GCC 4.7.

The configuration tested is:
- gcc version 4.7.2 (MacPorts gcc47 4.7.2_2)
- OpenBEAGLE-4.0.0-alpha2
- Mac OS X 10.8.2

So I do not understand what happenned in your case. I would advice you to look into the file $BUILD_DIR/CMakeFiles/CMakeOutput.log, to figure out what went wrong.

Best,

Christian

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "openbeagle-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to openbeagle-use...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Marc Segond]

Hi Christian,
thanks for the hint. Do you know if there is already some code
availbale? I will try to implement this solution as I definitely need to
take advantage of the 8 threads I can run on my comp. My GP system have
a huge set of example, this is why I wanted to parallelize the
evaluation loop, but I tried and it seems I cannot manage to do it as I
guess this Context problem is unsolvable (I tried in making a copy of it
for each thread, but it doesn't work)

Best

Marc

[Christian Gagné]

Hi Marc,

The Parity example contains somewhat such an example of vectorial evaluation, see files ParityFastMain.cpp, ParityFastEvalOp.hpp, and ParityFastEvalOp.cpp. But it also includes another trick, which is to make use of bitwise operations, as the test cases, bits here, are packed into an integer. Therefore, you need to deconvolve these two things to adapt it to your application. But I would say in general that as far as you get the idea, passing to vectorial evaluation should be relatively straightforward for your code. There is no special trick to do, only specify correctly you datum and primitives to work in a vectorial mode, and that will work out of the box.

As for duplicating the Context, that's normal that this do not solve the issue you have, as each Context contains a **reference** to the System (which itself contains the PrimitiveSet), which is not duplicated.

Christian

Christian Gagné
http://vision.gel.ulaval.ca/~cgagne

[Marc Segond]

Hi Christian,

On 02/26/2013 04:04 PM, Christian Gagné wrote:
> Hi Marc,
>
> The Parity example contains somewhat such an example of vectorial evaluation, see files ParityFastMain.cpp, ParityFastEvalOp.hpp, and ParityFastEvalOp.cpp. But it also includes another trick, which is to make use of bitwise operations, as the test cases, bits here, are packed into an integer. Therefore, you need to deconvolve these two things to adapt it to your application. But I would say in general that as far as you get the idea, passing to vectorial evaluation should be relatively straightforward for your code. There is no special trick to do, only specify correctly you datum and primitives to work in a vectorial mode, and that will work out of the box.

Thanks, I will do this!

>
> As for duplicating the Context, that's normal that this do not solve the issue you have, as each Context contains a **reference** to the System (which itself contains the PrimitiveSet), which is not duplicated.

I suspected it ;)
>
> Christian
Marc