LifeAPI - New GOL API (in C++)

For scripts to aid with computation or simulation in cellular automata.
User avatar
simsim314
Posts: 1823
Joined: February 10th, 2014, 1:27 pm

LifeAPI - New GOL API (in C++)

Post by simsim314 » December 12th, 2014, 12:20 pm

I was recently working on a way to make the usual search I've write in python (for Golly) much faster.

This is why I created the LifeAPI - this is VERY fast API, that includes a lot of functions, allowing the flexibility and simplicity of scripting, while still conducting extremely fast searches. Obviously it's not as comfortable as python (you still bounded by C++ syntax), but it's very comfortable and usable, while GOL is hard-coded into bit-wise operations.

It require only basic ability of compiling C++ code (g++ recommended), and requires only #include "LifeAPI.h". No Make is needed, no other files or special utilities - it's as simple as it gets.

It's currently limited to 64x64, I find this limitation pretty minor for many small objects searches. While for larger objects "HashLife" is preferred choice anyway.

I've attached the LifeAPI.h itself, ReadMe.txt with full documentation, LifeAPISample.c for simple example. For more samples see the project in sourceforge.

I hope you'll enjoy LifeAPI and it will assist in many new GOL discoveries.

EDIT I didn't include any licensing, but obviously no guarantee is given on anything, and you can use the code as you wish.

EDIT Moved to Github with formatted ReadMe and a bit more functions in LifeAPI.
Attachments
LifeAPISample.c
(2.78 KiB) Downloaded 631 times
LifeAPI.h
(16.98 KiB) Downloaded 640 times
ReadMe.txt
(10.41 KiB) Downloaded 625 times
Last edited by simsim314 on December 13th, 2014, 11:11 am, edited 2 times in total.

User avatar
codeholic
Moderator
Posts: 1147
Joined: September 13th, 2011, 8:23 am
Location: Hamburg, Germany

Re: LifeAPI - New GOL API (in C++)

Post by codeholic » December 13th, 2014, 7:16 am

Nice start. I wish some functions from gencols, ptbsearch, sngdetect etc. were compatible. Why did you choose C++ and not just plain C by the way? (I'm also deeply dislike CamelCase, but that's personal.)

Another thing which I found not quite optimal is the way you store states. I think storing only coordinates of live cells is more CPU and storage efficient than storing the whole grid. I wonder, if one can borrow some prior art for this purpose.

I've created an organization on GitHub. I find it much easier to collaborate on GitHub, than on SF. Shall I add your GitHub account in the org?
Ivan Fomichev

User avatar
simsim314
Posts: 1823
Joined: February 10th, 2014, 1:27 pm

Re: LifeAPI - New GOL API (in C++)

Post by simsim314 » December 13th, 2014, 10:34 am

codeholic wrote: I wish some functions from gencols, ptbsearch, sngdetect etc. were compatible.
I'm not so greatly familiar with gencols, but as i understand it's just takes two patterns, evolve one of them, place together and checks the result. This is very simply done by coding. With coding you can also do some checks that would be harder to pass as input parameters to gencols.

sngdetect - haven't heard of it.

ptbsearch - I'm not familiar with, but catgl I know, and rewriting it with LifeAPI shouldn't be too hard.
codeholic wrote: Why did you choose C++ and not just plain C by the way?
C++ has overloads. You can call, Transform with rotation, without rotation etc. C doesn't allows that. This is the main reason - I would probably prefer C otherwise.

Anyway C++ that I'm using is the same speed as C - I've checked this for few important functions (like Evolve), and as long as you don't overuse namespace std, C++ is as fast as C.
codeholic wrote:I'm also deeply dislike CamelCase, but that's personal
I know that people in this community for some reason don't like to use CamelCase. I really don't like snake_case. But golly seems to avoid this issue.

Maybe it's possible to release version with lowercase like golly python API. I've converted LifeAPI to lowercase, and there were only two issue:

1. new - is preserved word. Replace it with init.
2. null - is not recognized.

Anyway this was very painless conversion if someone just can't use CamelCase (I've attached the lowercase version).
codeholic wrote:Another thing which I found not quite optimal is the way you store states. I think storing only coordinates of live cells is more CPU and storage efficient than storing the whole grid. I wonder, if one can borrow some prior art for this purpose.
I wonder how so? The processor is working on 64 bit stream in parallel. Each clock tick is actually 64 bit operations. So if you have 64 bit and 1 Ghz processor, you actually have 64 Ghz processor. Now assume you can utilize every bit operation the processor has for life computing... you'll get something extremely fast. Instead of adding each cell value 8 times you will add 64 cells values.

My implementation was able to run 2M 64x64 iteration in second, on single core of 64 bit machine. This is before the min-max optimization.

codeholic wrote:I've created an organization on GitHub. I find it much easier to collaborate on GitHub
Agree, SF started to really annoy me. I've moved to github now.

You're are more than welcome to add a link to my repository.

---

By the way I've recently managed to compile lifesrc, made one huge file from it. I'm not sure about copyrights etc. but if you interested I can post it as well.
Attachments
LifeAPI.h
(18.55 KiB) Downloaded 614 times

chris_c
Posts: 966
Joined: June 28th, 2014, 7:15 am

Re: LifeAPI - New GOL API (in C++)

Post by chris_c » December 13th, 2014, 2:30 pm

simsim314 wrote: Agree, SF started to really annoy me. I've moved to github now.
Looks good. I made some patches for you to take a look at

https://github.com/simsim314/LifeAPI/pull/1

User avatar
simsim314
Posts: 1823
Joined: February 10th, 2014, 1:27 pm

Re: LifeAPI - New GOL API (in C++)

Post by simsim314 » December 13th, 2014, 4:41 pm

Hey that's great! I've merged your fixes into the main branch now.

Just of curiosity, why do you need Get Boundary? For the negative target, or something more exotic?

EDIT By the way do you want to be mentioned in the title (the commented section) of LifeAPI ?
Last edited by simsim314 on December 13th, 2014, 6:09 pm, edited 1 time in total.

User avatar
codeholic
Moderator
Posts: 1147
Joined: September 13th, 2011, 8:23 am
Location: Hamburg, Germany

Re: LifeAPI - New GOL API (in C++)

Post by codeholic » December 13th, 2014, 4:55 pm

simsim314 wrote:I wonder how so? The processor is working on 64 bit stream in parallel. Each clock tick is actually 64 bit operations. So if you have 64 bit and 1 Ghz processor, you actually have 64 Ghz processor. Now assume you can utilize every bit operation the processor has for life computing... you'll get something extremely fast. Instead of adding each cell value 8 times you will add 64 cells values.
I meant primarily searching and modifying patterns (finding and cutting subpatterns, in particular), rather than evolving. But you're probably right.
Ivan Fomichev

User avatar
simsim314
Posts: 1823
Joined: February 10th, 2014, 1:27 pm

Re: LifeAPI - New GOL API (in C++)

Post by simsim314 » December 13th, 2014, 6:24 pm

codeholic wrote:I meant primarily searching and modifying patterns
There are bitwise solution for that as well, which work even faster than FFT (for small objects). Anyway heavy pattern matching on each iteration, is obviously very time consuming, but I guess there are many time some work around (using bitwise operations), that in practice will work extremely fast.

One idea is to filter with some bitwise operation, to reduce the amount of options, and then check the options one by one - shouldn't take more than 500 clock cycles for typical pattern, which is not great - but very manageable.

Finally one can do some sort of bitwise FFT (say using modulus calculus for FFT or something of that sort).

---

Anyway LifeAPI wasn't intended to replace all search utilities, it was made mainly to make simple python like searches in golly much faster.

I think in this sense it covers a lot of golly functionality and even more, together with maintaining simplicity and flexibility, which is what I like about golly python API.

chris_c
Posts: 966
Joined: June 28th, 2014, 7:15 am

Re: LifeAPI - New GOL API (in C++)

Post by chris_c » December 13th, 2014, 7:35 pm

simsim314 wrote: Just of curiosity, why do you need Get Boundary? For the negative target, or something more exotic?
Yeah, just as an easy way to get the "unwanted" cells for a LifeTarget, so not performance sensitive at all.
simsim314 wrote: By the way do you want to be mentioned in the title (the commented section) of LifeAPI ?
Yeah no problem to mention me as a contributor.

User avatar
simsim314
Posts: 1823
Joined: February 10th, 2014, 1:27 pm

Re: LifeAPI - New GOL API (in C++)

Post by simsim314 » December 13th, 2014, 8:30 pm

chris_c wrote:Yeah no problem to mention me as a contributor.
Cool.
chris_c wrote:Yeah, just as an easy way to get the "unwanted" cells for a LifeTarget, so not performance sensitive at all.
Yes I added new constructor, that accept only one LifeState, the unwanted part calculated automatically with your GetBoundary. Also if it's not time sensitive why didn't you just calculate i - 1 as (N + i - 1) % N. Or just create a function to CirculateModN. The way you wrote it, seems to squeeze the last tiny bit of avoid unnecessary conditions and calculations.

Anyway this is great addition indeed. Take a look I've committed some new overloads.

I also start to invest in Captures everywhere. Every function can accept integer, and it will mean Captures[idx].

Here is a snippet of how simple it is:

Capture(0);
Run(2);
if(AreEqual(0)) ...

The last line means if GlobalState and Captures[0] are equal. This is simple check for p2 only detection.

This really feels like scripting game, rather than "heavy" programming, this is exactly what I intended.

---

Anyway committed the changes with the mentioned above and you as contributor.

chris_c
Posts: 966
Joined: June 28th, 2014, 7:15 am

Re: LifeAPI - New GOL API (in C++)

Post by chris_c » December 13th, 2014, 9:15 pm

simsim314 wrote:Yes I added new constructor, that accept only one LifeState, the unwanted part calculated automatically with your GetBoundary.
Cool, I thought you might want to do that.
simsim314 wrote:Also if it's not time sensitive why didn't you just calculate i - 1 as (N + i - 1) % N. Or just create a function to CirculateModN. The way you wrote it, seems to squeeze the last tiny bit of avoid unnecessary conditions and calculations.
I'd much prefer it if the mod operator worked like in Python with (-1 % N) == N-1. Refusing to use things like (N + x) % N just in case x is negative is my own silent little protest against that.
simsim314 wrote: Here is a snippet of how simple it is:

Capture(0);
Run(2);
if(AreEqual(0)) ...

The last line means if GlobalState and Captures[0] are equal. This is simple check for p2 only detection.
Hmmm.... yes that's nice short code, but I'm a little but torn on the use of Captures. I can imagine some seriously annoying bugs if you forget which pattern you stored in slot 0 and which in slot 1. Or imagine you write some code using some various capture slots, forget about it, and then revisit the code say 1 month later. Yikes!? What was Capture[0] was supposed to be doing?!

Or you have some old "simple" code that just uses Capture[0]. No problem, what could ever go wrong? Later you decide the code needs to do something more complicated in the middle, but you forget you already used Capture[0] and go and use it again. Argh!? It's bug hunting time.

Probably I would prefer the option to go slightly more long-hand:

Code: Select all

CopyState(old_state);
Run(2);
if (StateEquals(old_state)) ...

User avatar
simsim314
Posts: 1823
Joined: February 10th, 2014, 1:27 pm

Re: LifeAPI - New GOL API (in C++)

Post by simsim314 » December 13th, 2014, 10:08 pm

chris_c wrote: Later you decide the code needs to do something more complicated in the middle...
Maybe it's just me. I rarely reuse most of the code. Most of my scripts are kinda write and throw. I really don't care how I write them, and I prefer to write from scratch rather than reuse the existing code.

This is of course why I want to have kind of API, that will allow "garbage" coding. Python is more or less where I do all the "write and throw" stuff. If I have some more serious code, I really write it totally differently.

Now the point of Captures, is to give you great 5 minutes coding experience, you write three lines and feel you're the kind. If you intend to make something serious, I would say write nice and elegant code that can be understood and reused. But then why not to place it into LifeAPI itself?

The Captures feature is just to make life easier, faster, and simpler. You can always do it the hard way.

Most of my current scripts are initialization, iteration and match target (or just check population). This covers a lot of GOL searches, on the other hand it's coding, so you're not bounded by some N rules coded into input flags, you can make checks and tweak your search anyway you like, in very simple and user friendly way.

----

By the way I added now a constructors for TargetState from rle. Now targets and states are very similar for initialization. This GetBoundary is really great simplification.

---

EDIT I thought of another point - if we will have GUI at some point, one would be able to see all the captures in real-time as well. The capture could be a very simple way to debug stuff, and actually simplify your life (you can see most of your used objects all the time in real time).

User avatar
simsim314
Posts: 1823
Joined: February 10th, 2014, 1:27 pm

Re: LifeAPI - New GOL API (in C++)

Post by simsim314 » December 14th, 2014, 12:30 pm

I've an idea to accelerate LifeAPI with GPU. Using already fast bit-wise life implementation with parallel programming on GPU unit, could really boost performance to an amazing speeds.

Did anyone had some experience to implement GOL with CUDA or OpenCL?

P.S. I was thinking about it, because FFT can be performed very quickly with GPU as well (in logN using memory of N^2 I think). This could be not only the fastest GOL Iterator but also the fastest pattern recognizer.

wildmyron
Posts: 1542
Joined: August 9th, 2013, 12:45 am
Location: Western Australia

Re: LifeAPI - New GOL API (in C++)

Post by wildmyron » December 14th, 2014, 10:28 pm

I haven't had any experience with GPU or CUDA, though it is something I'd dreamt of implementing, however, I thought you might like to have a look at this project / contact the guy responsible:

https://github.com/jaxry/colorful-life

It has a GPU implementation of the semi-totalistic rulespace (optionally with Generations history) on the Moore neighbourhood. The cell colour computations are all irrelevant to you but the rest may be helpful.
The 5S project (Smallest Spaceships Supporting Specific Speeds) is now maintained by AforAmpere. The latest collection is hosted on GitHub and contains well over 1,000,000 spaceships.

Semi-active here - recovering from a severe case of LWTDS.

User avatar
simsim314
Posts: 1823
Joined: February 10th, 2014, 1:27 pm

Re: LifeAPI - New GOL API (in C++)

Post by simsim314 » December 15th, 2014, 4:06 am

@wildmyron thx for the link, I've already found a lot of GOL implementations in CUDA.

This guy even implemented bitwise implementation of GOL in CUDA, and run performance check, to see x20 speed up.

Just hoped someone here had experience with GPU.

EDIT The other side of it would be to implement it in LifeAPI, while allowing the coding itself remaining exactly the same. As GPU is best with large life objects, one thing I had in mind is to use LifeIterator that accepts pointer to Setup, and Validate functions. Anyway This will require some syntax adjustment. I wanted the user just to write the same application, and CUDALifeAPI will know how to adjust. Maybe LifeAPI is not mature enough yet for that.

User avatar
codeholic
Moderator
Posts: 1147
Joined: September 13th, 2011, 8:23 am
Location: Hamburg, Germany

Re: LifeAPI - New GOL API (in C++)

Post by codeholic » December 15th, 2014, 4:54 am

simsim314 wrote:sngdetect - haven't heard of it.
It is a search program by Gabriel Nivasch, that is not very famous, probably because it yielded no fruit. But it has nice algorithms for enumeration of constellations and escaped glider detection.
Ivan Fomichev

User avatar
simsim314
Posts: 1823
Joined: February 10th, 2014, 1:27 pm

Re: LifeAPI - New GOL API (in C++)

Post by simsim314 » December 15th, 2014, 1:26 pm

codeholic wrote:But it has nice algorithms for enumeration of constellations and escaped glider detection.
It's a pretty good idea to have LifeIterator that automatically get's rid of emitted gliders. I'll look into it.

chris_c
Posts: 966
Joined: June 28th, 2014, 7:15 am

Re: LifeAPI - New GOL API (in C++)

Post by chris_c » December 16th, 2014, 6:20 pm

I made my first LifeAPI program. A search for a different central predecessor of 25P3H1V0.2. I figured that the hive looking things on the outside look buildable so that if I could find a central section that decomposes into two distinct halves then it may lead to a synthesis.

But after 2,000,000 iterations I had no luck :lol:

Here is the code. It depends on a couple of changes I made to LifeAPI here: https://github.com/simsim314/LifeAPI/pull/2

Code: Select all

#include "LifeAPI.h"

// Search for an alternative predecessor in the central  section of 25P3H1V0.2

int main() {

    New();

    LifeState *outside = NewState("12b3o$b3o11bo$o12b2o$b2o!");
    LifeState *mask = NewState("8o$8o$8o$8o$8o$8o!", 4, -2);
    LifeTarget *target = NewTarget("7b2obo$4b2obob2ob3o$b4o2b2o6bo$o4bo3bo3b2o$b2o!", 0, -5);
    LifeState *before = NewState();
    LifeState *after = NewState();
    
    for (int n = 0; n < 2000000000; n++) {

        RandomState(before);
        // Uncommenting this should give an instant hit
        // Parse(before, "3b2obo$2obob2o$o2b2o$bo3bo!", 4, -1);
        Copy(before, mask, AND);
        Join(before, outside);
        Evolve(after, before, 12);

        if (Contains(after, target)) {
            PrintRLE(before);
            return 0;
        }

        if (n % 65536 == 0)
            printf("%d\n", n);
    }

    return 0;
}

User avatar
simsim314
Posts: 1823
Joined: February 10th, 2014, 1:27 pm

Re: LifeAPI - New GOL API (in C++)

Post by simsim314 » December 16th, 2014, 8:06 pm

chris_c wrote:I made my first LifeAPI program.
Congrats! I'm glad I'm not the only one who enjoys tweaking it.
chris_c wrote:But after 2,000,000 iterations I had no luck
Hmm 2M is something that should run few seconds. Is this the case? If not I would say you did something wrong somewhere.
chris_c wrote: It depends on a couple of changes I made to LifeAPI
Great! I peeked a little bit at your changes, looks great.

Code: Select all

 RandomState(before);
I'm not sure how good idea is it... For your purpose, I want to build BitIterator. It will iterate on N bits, trying all combinations possible. The bit iterator most of the time will just add1. There is also a possibility, to make iterator, that copies the first iteration result into "after" immediately. This will save some time copying the same thing over and over, with small changes (if you just add1 each time - you want to keep the initial pattern untouched).

Another point is that you don't need 64x64 random soup - so you could use the min-max optimization while randomly filling much smaller space.

I'm also working on fast pattern recognition, this should allow this kind of "soup search" to be much more effective.

---

Small question: do you know if %2 and &1 working with same speed? because your change there is inside the iterator, and I wanted to squeeze each and every small bit of speed there.

chris_c
Posts: 966
Joined: June 28th, 2014, 7:15 am

Re: LifeAPI - New GOL API (in C++)

Post by chris_c » December 17th, 2014, 8:21 am

simsim314 wrote: Hmm 2M is something that should run few seconds. Is this the case?
Ooops, I meant 2 billion. It took maybe an hour or two.
simsim314 wrote: I'm not sure how good idea is it... For your purpose, I want to build BitIterator. It will iterate on N bits, trying all combinations possible.
Yes, BitIterator would be useful, but note that my mask area was 40 bits so it would be unrealistic to iterate through the entire space. Maybe I have proved that iterating over such a large space is not very useful anyway.
simsim314 wrote: Another point is that you don't need 64x64 random soup - so you could use the min-max optimization while randomly filling much smaller space.
Yes I suppose you could have something like RandomState(state, mask) to take advantage of this optimisation.
simsim314 wrote: Small question: do you know if %2 and &1 working with same speed? because your change there is inside the iterator, and I wanted to squeeze each and every small bit of speed there.
With

Code: Select all

int f(int x) { return x % 2 == 0; }
I get the following assembly output from "g++ -S":

Code: Select all

        andl    $1, %eax
        testl   %eax, %eax
        sete    %al
So, yes g++ seems to know about that trick even without any optimisation flags.

User avatar
simsim314
Posts: 1823
Joined: February 10th, 2014, 1:27 pm

Re: LifeAPI - New GOL API (in C++)

Post by simsim314 » December 17th, 2014, 9:22 am

chris_c wrote:Ooops, I meant 2 billion.
Sounds more like it.
chris_c wrote:Yes, BitIterator would be useful, but note that my mask area was 40 bits so it would be unrealistic to iterate through the entire space.
You could combine few BitIterators, and avoid continue iterating if contradiction was found in the beginning. It's kinda optimized brute force, but compared to lifesrc optimization.

Dumb 40 bits brute force should be reachable with GPU acceleration (around x20 speedup).

User avatar
simsim314
Posts: 1823
Joined: February 10th, 2014, 1:27 pm

Re: LifeAPI - New GOL API (in C++)

Post by simsim314 » December 20th, 2014, 9:55 am

I've merged your second pull request.

Added LifeString instead std string.

I want to say something about namespace std, that you might not be aware of. If you just write "using namespace std" in your code somewhere - this will kill your performance by 200%. I'm not sure why this happens, but this is verified fact. Even this simple fact, is good reason to use C instead C++ for performance sensitive applications. Of course using only std::vector, or std::string will not cause performance issues.

Now I'm not sure what causes this, as I've no sources for std namespace - and this is exactly my problem with it. A new namespace, that causes new issues if you use it wrongly, kills your performance, and no "real" source code available (to modify it simply), this is simply programmers worst nightmare, even if it's extremely popular.

Now I'm aware that C++ more or less started from std, but this is exactly why C is more popular than C++, this language has too many nuances, one step in wrong direction and go figure.

Another example form std: if you would return .c_str() it comes messed up. Why? you didn't allocate it, and the original class would be destroyed in destructor.

That's exactly my point - C++ has too many small nuances, and you can't take one class and adopt it (it's just too complicated even if you manage to do it). In C you always allocate stuff, you almost don't use instances - this simplifies things, a lot.

---

Obviously C is not perfect as well, overloads is simply must have for any programming language in my opinion. But other than that, I just try to stick to C syntax, as much as I can. Stuff like automatic allocations and size adaptions, is matter of 50 lines of code, and you in total control to modify it to your needs, giving you VERY simple implementation, so no bugs or performance issues there (not talking about missing libs).

chris_c
Posts: 966
Joined: June 28th, 2014, 7:15 am

Re: LifeAPI - New GOL API (in C++)

Post by chris_c » December 20th, 2014, 12:51 pm

simsim314 wrote:I've merged your second pull request.
Great, thanks. Here is another pull request: https://github.com/simsim314/LifeAPI/pull/3

User avatar
simsim314
Posts: 1823
Joined: February 10th, 2014, 1:27 pm

Re: LifeAPI - New GOL API (in C++)

Post by simsim314 » December 20th, 2014, 1:37 pm

@chris_c - Great thx to you

Meanwhile I like how LifeAPI is going, and as long as it's not becoming uncontrollable monster, I prefer to have it all in one place. Some more logical order of function definitions would help, but it's more or less it.

If LifeAPI will start becoming a really big monster, I will divide it into few directories (or as you said add LifeAPI.cpp).

I was thinking about using classes - but meanwhile I like this C style, it definitely has some advantages over the usual C++ way of doing things (for starters users can't create instances, they must use pointers - using New... I think it's great feature).

---

Another question: did you worked a little bit with CUDA or OpenCL? Do you have a clue how to allow LifeAPI flexibility together with GPU acceleration?

User avatar
simsim314
Posts: 1823
Joined: February 10th, 2014, 1:27 pm

Re: LifeAPI - New GOL API (in C++)

Post by simsim314 » December 20th, 2014, 2:18 pm

@chris - OK merged your request.

Added TargetLocator. You can now find any pattern, in LifeState, pretty fast - the TargetLocator will give you the locations of all Targets found in your current LifeState. I made it to fast remove emitted gliders from the state (I added array of emitted gliders, and gen to LifeState - to provide the output with data about them).

Anyway It's now possible to look for things like Hershel conduits, just add Hersch (in all 8 orientations) to TargetLocator (accepts rle in constructor), and Locate Hersch in each iteration, with pretty much minimal performance cost.

I'll soon add this option as built in option of the iterator (it will search for targets in each iteration), together with automatic emitted gliders removal (adding the data about them to LifeState).

EDIT Automatic glider removal is now committed into the master.

User avatar
simsim314
Posts: 1823
Joined: February 10th, 2014, 1:27 pm

Re: LifeAPI - New GOL API (in C++)

Post by simsim314 » December 25th, 2014, 5:51 am

I've added OpenMP (multi-threading) support for LifeAPI.

OpenMP provides very simple way to code parallel (CPU) applications, using simple #pragma directives in your code. This allows speedup LifeAPI on multi cores machines.

LifeAPI.h needed some moidfications so take mpLifeAPI.h instead. To see sample using omp in LifeAPI application see here. Everything major remains the same except of few special directives.

NOTE One can use the original LifeAPI.h with OpenMP. But you can't use any static objects, so everything should be done with ClearData, Join and Evolve instead of New, PutState and Run.

How To Use / Technical Details

First make sure OpenMP is working in your setup. Many compilers (g++ included) comes with omp support built in, but you need to add -fopenmp flag to the compiler.

Then to use omp in LifeAPI application you need three major things:

1. First create threads with #pragma omp parallel - and then use the first New(); - That means create a few threads to run in parallel.

2. in do...while(Next(..)) loop add #pragma omp single nowait. That means only one thread perform this operation inside the loop.

do{

#pragma omp single nowait
{
}

}while(Next(..));

NOTE You can't use continue directive inside omp block. Instead just add {...} blocks.

3. In report section you need to specify #pragma omp critical , to avoid overlapping few printfs from few threads.

#pragma omp critical
{
PrintRLE();
}

NOTE mpLifeAPI.h added only omp directives for static objects. Everything else remains the same as in LifeAPI.h.

Post Reply