Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » GCC versions

This thread is locked; no one can reply to it. rss feed Print
GCC versions
LennyLen
Member #5,313
December 2004
avatar

I want to install MinGW on my system, and I'm trying to decide which will be the best GCC version to install out of:

x86_64-posix-sjlj
x86_64-posix-seh
x86_64-win32-sjlj
x86_64-win32-seh

I'll only be targeting Windows, so is it worth getting a posix version? And what is the difference between the sjlh and seh versions?

Neil Roy
Member #2,229
April 2002

That's a good question. The last one I downloaded was the setup Edgar posted.

If I have to update it, I will be lost I think. ;D

bamccaig
Member #7,536
July 2006
avatar

Google suggests the difference between sjlj and seh is the exception handling mechanism. Google should be your friend here. I can't help more than that. In reality it probably won't matter, but the main thing is that you'll probably need all of your libraries/dependencies to be compiled using the same version you're using. I'm not sure if that's true, but I assume so.

Google suggests that the posix version will use a pthreads library for threading whereas the win32 version will use Windows threads. That shouldn't impact the code that you can write, but rather it affects how it gets implemented by the runtime. Apparently a caveat of the posix solution is that you need to distribute the additional DLL for the pthreads implementation, but that's pretty harmless in and of itself. I would wager that the win32 solution might perform better, but apparently then you can't use some fancy C++11 features that depend on the posix version in GCC. So for that reason you might lean towards the posix version.

The best answer is probably unless you have dependencies that requires a particular version it doesn't matter. Pick one and use it happily until you run into issues.

Worded a different way: if you don't know the answer then there is no answer. :)

LennyLen
Member #5,313
December 2004
avatar

bamccaig said:

Worded a different way: if you don't know the answer then there is no answer.

What you said is pretty much what I figured. Thanks.

Quote:

I would wager that the win32 solution might perform better, but apparently then you can't use some fancy C++11 features.

I'm not really familiar with C++ beyond they C++98 standard. I usually stick to either straight C or some bastardized version of C with classes.

bamccaig
Member #7,536
July 2006
avatar

If you aren't even using C++ (nor C++ runtimes) then I think it won't matter at all. Not sure if the whole compiler version conflict shenanigans is C++ only or if it affects C too. That said, Allegro now has some C++ abstracted behind C APIs, but I doubt any of them use exceptions and it probably doesn't use any threading.

Neil Roy
Member #2,229
April 2002

The version on my system now is a posix version <shrug>. Works for me.

I normally only do straight C, and as long as it supports the 2011 C standard (C11), I am happy.

I recently finally got around to trying out some thread code with C and SDL2 and it worked fine which was kind of kewl. I have a simple test program. I know very little about threads and should probably start using them... if I ever get around to programming anything serious again that is. ;)

#SelectExpand
1#include <stdio.h> 2#include <SDL2/SDL.h> 3 4// Very simple thread - counts 0 to 9 delaying 50ms between increments 5static int TestThread(void *ptr) 6{ 7 int i; 8 9 for (i = 0; i < 10; i++) { 10 printf("Thread counter: %d\n", i); 11 SDL_Delay(50); 12 } 13 14 return i; 15} 16 17int main(int argc, char *argv[]) 18{ 19 SDL_Thread *thread = NULL; 20 int threadReturnValue = 0; 21 unsigned int endTime = 0, startTime = 0; 22 23 printf("Simple SDL_CreateThread test:\n"); 24 25 startTime = SDL_GetTicks(); 26 27 // Simply create a thread 28 thread = SDL_CreateThread(TestThread, "TestThread", (void *)NULL); 29 if (thread == NULL) 30 printf("SDL_CreateThread failed: %s\n", SDL_GetError()); 31 else { 32 for (int i = 10; i < 20; i++) { 33 printf("Main counter: %d\n", i); 34 SDL_Delay(50); 35 } 36 SDL_WaitThread(thread, &threadReturnValue); 37 printf("Thread returned value: %d\n", threadReturnValue); 38 } 39 endTime = SDL_GetTicks(); 40 41 printf("Time Elapsed: %d\n", endTime - startTime); 42 43 printf("Normal counting to 20:\n"); 44 startTime = SDL_GetTicks(); 45 for (int i = 0; i < 20; i++) { 46 printf("Normal counter: %d\n", i); 47 SDL_Delay(50); 48 } 49 endTime = SDL_GetTicks(); 50 printf("Time Elapsed: %d\n", endTime - startTime); 51 52 return 0; 53}

....anyhow, that compiled and ran fine with the GCC I have: "gcc version 7.1.0 (i686-posix-dwarf-rev0, Built by MinGW-W64 project)"

SiegeLord
Member #7,827
October 2006
avatar

You basically never want sjlj (setjmp/longjmp), as unlike seh/dwarf it's not 'free' in the sense that you don't pay for exception handling if you don't throw an exception. You'd only choose sjlj if your prebuilt dependencies used it, or the compiler just didn't support it (shouldn't be true in this day and age). Don't know about posix vs win32, except that msys2 uses posix, so I'd just follow their lead.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

bamccaig
Member #7,536
July 2006
avatar

Neil Roy said:

I know very little about threads and should probably start using them..

On the contrary, unless you have a good use for them you should avoid them like the plague. Threaded programs are notoriously difficult to get right in low-level languages. Unless it's necessary it will likely just lead to more bugs and more headaches and troubles than it's worth. The promise of having multiple things running in parallel is great, but in practice it's very difficult to reason about these kinds of programs in a language that wasn't designed from day one with this in mind (and even then, it can be a brainfuck). Easiest case is you fire off a thread to do some difficult work, have it work in complete isolation from the rest of the program, and then have it respond with some data that is untouched until the thread is joined back again with the main program. That could be a simple win. When you have multiple threads trying to read or manipulate the same data in parallel though it generally just results in brainfuck and obscure bugs. :P If you want to really, really play with threads consider a more modern language that was designed to do it (but from the sounds of it no language really does it well yet).

LennyLen
Member #5,313
December 2004
avatar

I ended up installing the posix version as I couldn't be bothered building A5 myself. A few adjustments to Code::Blocks toolchain settings and Hello World compiled fine.

I think I'll finally get around to learning A5. I lost all my prior Allegro projects so I'm starting from scratch anyway.

edit:

Neil Roy said:

I have a simple test program.

You'll probably want the program to exit after it prints the error message if the thread creation fails.

edit 2:

And now I remember that I wanted to try giving Visual Studio a try for C++ programming, so I've just used nuget to install Allegro for me.

Neil Roy
Member #2,229
April 2002

LennyLen said:

You'll probably want the program to exit after it prints the error message if the thread creation fails.

I thought it did... I must have changed something along the way. Ah well, it didn't fail, but worked perfectly for me. I will probably mess with them some more just for shits and giggles.

Edit: I added extra code onto the end of that to run a test to count without threads later on. Initially, if thread creation failed, it would jump to the end of the if/else statement and exit normally, so there was no need. I later add on code to time it and additional test code, but it is still safe. An exit(1) would be nice, but not hazardous. The else{} portion will not execute if the thread is not created, so no problems. It was just quick test code, nothing major.

This was the code before I added more to it...

#SelectExpand
1#include <stdio.h> 2#include <SDL2/SDL.h> 3 4// Very simple thread - counts 0 to 9 delaying 50ms between increments 5static int TestThread(void *ptr) 6{ 7 int i; 8 9 for (i = 0; i < 10; i++) { 10 printf("Thread counter: %d\n", i); 11 SDL_Delay(50); 12 } 13 14 return i; 15} 16 17int main(int argc, char *argv[]) 18{ 19 SDL_Thread *thread = NULL; 20 int threadReturnValue = 0; 21 22 printf("Simple SDL_CreateThread test:\n"); 23 24 // Simply create a thread 25 thread = SDL_CreateThread(TestThread, "TestThread", (void *)NULL); 26 if (thread == NULL) 27 printf("SDL_CreateThread failed: %s\n", SDL_GetError()); 28 else { 29 for (int i = 10; i < 20; i++) { 30 printf("Main counter: %d\n", i); 31 SDL_Delay(50); 32 } 33 SDL_WaitThread(thread, &threadReturnValue); 34 printf("Thread returned value: %d\n", threadReturnValue); 35 } 36 37 return 0; 38}

...as you can see, initially, if thread creation failed, it would jump to the return 0; and exit. I added to this later on, but it is still safe. If thread creation fails, all it will do now is run the second part of the code which doesn't use them.

bamccaig said:

On the contrary, unless you have a good use for them you should avoid them like the plague.

As for C and threads, any arguments against it doesn't make any sort of sense as C++ wasn't designed with them in mind EITHER, so that is utter nonsense. C11 on other other hand was designed to use them along side C++11.

In any event, I tried them out and they worked no problems. But then, I also don't have a problem using pointers either, even though I hear about all sorts of scary scenarios which just don't happen, with me anyhow. I have more problems when I forget a semicolon than I do pointers. So I doubt very much I will have problems with threads. I can envision a lot of good uses for them and absolutely plan to give them a shot. It will be nice to learn to use them, and learn to use them in C. Like I do everything else. :)

I'll trust a low level language to do them, and do them better over a high level, convoluted mess like C++. But that's just me. I haven't been brainwashed about C++ yet.

LennyLen
Member #5,313
December 2004
avatar

Neil Roy said:

I also don't have a problem using pointers either, even though I hear about all sorts of scary scenarios which just don't happen

That and trying to write anything non-trivial in C without using pointers is pretty much impossible.

Edgar Reynaldo
Member #8,592
May 2007
avatar

Neil Roy
Member #2,229
April 2002

Personally, I use the Posix SEH version of MinGW-W64 gcc 7.1. Haven't had any problems with it, but then I compile everything myself, so compatibility wouldn't be an issue.

Awesome, now I know what to get next time. ;) Still using 7.1 you posted.

Edgar Reynaldo
Member #8,592
May 2007
avatar

bamccaig
Member #7,536
July 2006
avatar

Neil Roy said:

As for C and threads, any arguments against it doesn't make any sort of sense as C++ wasn't designed with them in mind EITHER, so that is utter nonsense. C11 on other other hand was designed to use them along side C++11.

I wasn't implying to use C++. ::) That's worse than C. I was referring to modern languages, like maybe Go or something dynamic.

Neil Roy
Member #2,229
April 2002

I only know C or C++ and very little else. Both C and C++ were designed to use threads in 2011, possibly earlier, I don't know, but they both worked together to keep the languages compatible. Sadly, there hasn't been a C11 implementation that has threads as it was optional. But I tried out SDL2 threads with C and they worked well.

My main interest in them would be something like in my Deluxe Pacman 2 game, I have a function that searches for the best path for ghosts to take to reach the player, and that could be improved if that was calculated in a thread. I could see it greatly speeding things up without making things too complicated.

bamccaig
Member #7,536
July 2006
avatar

The main problem with threads is keeping them synchronized. It's trivial to start them up, and join to them again. Those APIs aren't hard to understand. What's difficult is allowing them to both access the program's mutable data without bugs. It's not the same thing as beginners being "afraid" of pointers because they're ugly. It's a truly difficult problem in some cases that even experienced professions can struggle to get right. C# and Java have had thread APIs for years, but that still doesn't make it easy to manage them.

Random link for reference: https://stackoverflow.com/questions/660621/threading-best-practices

Audric
Member #907
January 2001

Neil : There is 99% chances that your pathfinding/decision algorithm needs a non-changing situation to examine (ie. the algorithm would break horribly if the board changed while it was examining it) Because of this, you'll have a prerequisite of making a copy of the board (a snapshot) for the pathfinding thread to examine.
When the task is complete, it has produced a "plan" for the ghosts. But you have to take into account that the situation has changed :
- a ghost may have been eaten and respawned, his plan should be cancelled
- a ghost may have already passed a turn it should have made. Can they turn back or is it forbidden ?
Also, if such algorithm typically takes 1 second (for example), is it ok to aim for the current player position ? Or should you try predict his position "in one second" ? It's the kind of question you'll have to ask yourself.

Neil Roy
Member #2,229
April 2002

Well, what I have already works, and the way I implemented it doesn't depend on any one ghost. I can update the path data as the pacman moves without even looking at a ghost! All ghosts look at the same data. If a ghost dies or whatever, it just doesn't matter. The path data is global and only needs to be updated as the player moves to a new cell. But it can take some time due to how it is implemented, not much, and for this game, it doesn't matter, it's just something I thought would be a good application of threads.

If they turn out to be too much of a headache, I will ditch them. It's more of a curiosity thing with me, trying something new (to me).

When it comes to how my ghosts move, they check the path data, which will tell them which of the neighbouring cells in the directions the ghost can move in is the shortest path leading to the player and then it decides whether or not to take it. Even if the player moves, the path data will not change that much, as he will only be a cell in any one of four directions and the start of the path, the only part that really matters to the ghosts won't change in most cases.

If you play my game (Deluxe Pacman 2) on hard mode, how the ghosts act totally changes and I use the same algorithm the arcade game uses which doesn't involve paths, which can be fun to play on as on hard mode, my game's ghosts all have their own personality. It was fun to read about (and see the original machine code) for the arcade game. The arcade game actually had a bug in the code for the ghosts (one of them anyhow), which I fixed for my routine. I think threads would work for how I do it.

I figured, start a thread early to calculate the paths, then when you need them, wait for the thread to finish if it is still busy, it still won't be as long a wait as when I need to do a total update from scratch. I really don't see how that could go wrong (famous last words, LMAO).

bamccaig
Member #7,536
July 2006
avatar

That seems dependent on the machine having other "virtual processors" to do the processing in parallel. If not, it might well be slower than the single-threaded approach. I imagine it's up in the air whether you gain anything anyway. The only way to be sure would be profiling, but if you don't have any bottlenecks doing it single-threaded then you won't likely be able to determine if it's better or worse (it just won't matter either way, aside from code complexity). Still, I encourage you to look into threads for fun and to increase your own knowledge. That's always a good thing. Just don't go overboard thinking threads are a holy grail. I think in most cases, unless a thread is necessary, it ends up actually being more of a burden than a cure.

Neil Roy
Member #2,229
April 2002

Well, I ran a test program that counted through a loop from zero to 19 (20), with threads I had one loop count to 10 while at the same time a thread counted another 10. I then ran a normal loop which counted to 20 and timed it all and the threaded version done it in half the time.

I don't think there's any CPUs out there that can't do this. Heck, my CPU is like 9 years old now, something like that and it can! ;) If yours can't, go to a dumpsite and grab a better one. ;D

Go to: