Can't Compile Multithreaded BlitzMax + Leadwerks

[Guy Rabiller]

Hello,

 

For rapid prototyping I'm currently using BlitzMax ( and the great BLIde ) with the Leadwerks engine modules.

 

It seems I can't compile with the Multithreaded option turned on.

 

I understand the Leadwerks engine is not thread safe but I would like to be able to use threads for tasks unrelated to the engine.

 

Is this a known issue ? Is there a workaround to this, an update or something I'm not aware of ?

 

Thanks in advance for your help.

 

Guy.

[Josh]

Multithreaded compiling is not supported.

 

I have built the engine in MT mode, and it ran so slow it's not worth bothering with, like 15% the speed the ST mode runs at. BMX's multithread implementation is mostly useless, because it relies on a different garbage collector that is much slower. Making BMX garbage-collected was a huge design mistake, in my opinion, and this is just one more reason why.

 

The engine also relies on the reference-counted (ST) GC at some points, and will crash without it.

[Guy Rabiller]

Ah, I see.

 

Thanks for the information Josh.

 

Well, I'm just using BlitzMax for prototyping anyway, so no big deal.

 

The final application will be in C and hopefully in 64 bit ( hence my other question regarding 64 bit version of the engine in the main Programming forum ).

 

Guy.

[TheoLogic]

Hello Guy, just out of interest, why C, and why (only) 64bit?

[Canardia]

why (only) 64bit?

I don't think many people have 128-bit or 256-bit computers yet, so 64-bit is enough for now

[Guy Rabiller]

Hello TheoLogic,

 

Hello Guy, just out of interest, why C../..

 

Well, it's mostly for historical and personal reasons actualy, not because C is better than.. or whatever. I've developped along the years lot of things, libraries etc.. and I don't want to waste time porting everything to C++ now.

 

That said, the C I use is an Object Oriented C (OOC), - based on an old paper from Axel-Tobias Schreiner ( I don't use a pre-processor though ) - wich use Flexible Array Members (FAM) a lot ( and FAM are not supported by C++ ), plus some custom modifications/additions, so I have classes, inheritance, interfaces, objects encapsulation, etc.. and even, to some degree, templates. I don't have overloading though.

 

This OOC has a few interresting features, for instance object construction from the stack is done manualy ( _ctor( obj ); ) wich means if I don't need an object due to some conditions, the object is not constructed at all. Using this OOC is a little more work than using plain C++ for sure, but I'm ok with it.

 

The thing is that to use C++ efficiently, IMHO, you must use templates. And using templates is not an easy task, especialy when debugging. So for now I'm pretty happy and confortable with this OOC and I don't see the benefit, at least for now, for me to sitch to C++. In fact I rely on scripting too ( Squirrel ) so once the low level / hardcore functionalities are implemented in OOC I can switch to a higher level of abstraction using this OO scripting language ( with native classes, etc. ).

 

This works pretty well so far and I'm pretty happy with this combination.

 

../..and why (only) 64bit?

I don't think many people have 128-bit or 256-bit computers yet, so 64-bit is enough for now

 

Hehe, good answer Lumooja

 

Well, our projects and applications mostly target recent graphic cards, so there is no point for us to support old cards and old OS. Current OS are 64bit, I see no point to support 32bit anymore.

 

Plus we are mostly targetting professionnals ( we are not in the game industry ) and in this context and in the context of our applications, memory usage can be important. Scenes using 8Gb or more are not uncommon. Plus, clearly, we are not targetting mobile platforms and so on, so I see no reason at all to support 32bit application anymore, at least for us

 

Guy.

[Canardia]

Yes, 64-bit makes mostly sense for artists today, who get speed benefits from the additional memory above 4GB. A 64-bit system is generally slower than a 32-bit system, but the amount of RAM makes the 64-bit system faster, if the applications can use it.

[TheoLogic]

Interesting, I never heard about OOC but it seems it looks a lot like C++. I should tell you to take a look at the STL. A lot of the template magic and meta programming has been done for you, no need to reinvent those things.

I do not however agree that you must use templates in C++. C++ supports templates, and is useful for generic development, but 95% of my code involves no templates at all (at least not directly, for example by using the STL). With the upcoming, almost completed new ISO standard, you get new algorithms, containers, smart pointers logic, variadic templates, initializer list, ... where the biggest performance booster would be rvalue references empowering move semantics and perfect forwarding. Even if you do not plan to use this, I would suggest to take a look at it, you can find some very interesting design patterns there.

 

Targeting professionals on 64bit is as clear as the answer to my question can get .

[Guy Rabiller]

Well, you don't need to 'sell' me C++

 

I know C++ and I've used it a lot for some developments by the past, but at the end I guess it just goes down to a question of personal tastes.

 

Also perhaps at some point I prefere to concentrate on the project itself rather than the intricacies of the used language(s). In C++ if you want to be efficient, you must use templates, either directly or indirectly. You have the standard library but also heavy libraries too ( boost, etc.. ). Then the standard is evolving, new features, etc.

 

The thing is that the time you spend to learn, understand, test, make decisions about the right approach(es), libraries, etc.. is not spent on the actual development. I am at a point where by using C and the simple OOC idea, I can concentrate on the actual development rather than on the language itself.

 

I don't know why but when it comes to high level object oriented approaches I tend to shift to scripting languages, especialy Squirrel ( or even some RAD dev tools, I've used RealBasic, PureBasic in some production environments where dev time was a big issue ) ( BlitzMax only for prototyping with LE ) and when it comes down to more low level stuff I prefer C. Perhaps I'm too old to change my habits

 

But again, don't get me wrong, I'm not telling one is better than the other one.

[TheoLogic]

I'm not trying to sell you C++ . But if you say C get's the job done faster, in 75% of the cases I will not agree. In C you just need to get everything right to keep the compiler satisfied. Doing this, even when you have reusable code, you still miss some constructs like a red-black tree or hash tables, dynamic arrays, ... Constructing those from scratch in a real pain in the bum.

I do agree that if you don't know C++, and some other language, you will probably get there faster .

[Canardia]

The reason why BlitzMax compiles so fast is that it uses MinGW, while LE2 with C++ normally uses Visual Studio. But since LE2 can now also be compiled using Code::Blocks with MinGW, it's as fast as the BlitzMax compiler. This is a huge boost in productivity since you can now compile and run your program in 2 seconds.

[Rick]

The thing is that the time you spend to learn, understand, test, make decisions about the right approach(es), libraries, etc.. is not spent on the actual development. I am at a point where by using C and the simple OOC idea, I can concentrate on the actual development rather than on the language itself.

 

That sounds more like you are just more comfortable with C than C++ so you are faster with it. If you would learn C++ more and use it more you would be converted, but you would have to approach it in such a way of learning instead of getting a project done. That's just making the learning and using part a priority instead of just getting a project done.

 

 

This is a huge boost in productivity since you can now compile and run your program in 2 seconds

 

vs what? 10 seconds? You remind me of a Saturday Night Live skit back in the day where they did an infomercial that will save you seconds in the day by shortening words when you talk.

[TheoLogic]

The reason why BlitzMax compiles so fast is that it uses MinGW, while LE2 with C++ normally uses Visual Studio. But since LE2 can now also be compiled using Code::Blocks with MinGW, it's as fast as the BlitzMax compiler. This is a huge boost in productivity since you can now compile and run your program in 2 seconds.

 

You can optimize VS build speed, but the main reason why it's slower would be the optimizations. If you take a look at the VS STL you will see a lot of meta template programming, which will take extra compile time. On the other hand: the time you win while compiling, you will loose with the IDE. VS has a bunch of features, shortkeys, plugins, ... Saving you more are the seconds when compiling . But again, all comes down with what you feel good with. If you prefer code::blocks, just use it, use notepad if you like!

The main thing is to get the job done, how you do it doesn't really matter that much.

[Canardia]

Actually I found that Code::Blocks has much more useful features than VS. For example the ability to include different source files for Debug and Release modes (or any other custom modes you define).

Also the syntax highlighting is better than in VS, as you can give different colors to user keywords and system keywords, and you can also manage multiple keyword lists directy from the IDE, while in VS you only have only file on disk. Also Intellisense is better than in VS, as it doesn't create a insanely huge cache file (10-30 MB), but does everything in realtime and much faster.

[TheoLogic]

Those sound useful, but you can achieve most of them in VS...

Building different sources in different build modes is I personally think in general a very bad idea. This is pretty error prone, and you can mix up those settings really quickly. I prefer building libs, and linking the lib I need for the build configuration I need.

Syntax highlighting workaround would be visual assist, combined with the default IDE Tools -> fonts and colors.

Intellisense is indeed a tad slow, much better in VS2010 with the light SQL DB. Much better results again with visual assist. You are stuck with the DB file, I admit.

 

On the other hand, things I use every minute I code:

- Cut/Copy/paste whole line

- Open header/cpp (va)

- Create implementation (va)

- Add include (va)

- ...

can not be done in code::blocks.

 

But again, this all depends on the user .