The Boost issue (again)
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: The Boost issue (again)
Yeah, MinGW lost a lot of its appeal ever since they started to fall behind the current GCC releases. I mean, MinGW is still stuck with GCC 3.4.5, and let's face it, that version is just not good enough anymore. There is some alpha release of a GCC 4 version, but that download is some months old. I sure hope they catch up some time soon!
- pianoman
- Halfling
- Posts: 47
- Joined: Sun Feb 08, 2009 10:52 pm
Re: The Boost issue (again)
I don't believe it! I didn't see ANYTHING in the license restricting commercial software!
I give everyone here permission to laugh at, mock, and scorn me.
So why does ANYONE use MinGW? No wonder most libraries don't care about MinGW. Shucks, I knew I could count on you guys in the Ogre community. (I hope you're not still scorning me...)
Thank you!
I give everyone here permission to laugh at, mock, and scorn me.
So why does ANYONE use MinGW? No wonder most libraries don't care about MinGW. Shucks, I knew I could count on you guys in the Ogre community. (I hope you're not still scorning me...)
Thank you!
- xavier
- OGRE Retired Moderator
- Posts: 9481
- Joined: Fri Feb 18, 2005 2:03 am
- Location: Dublin, CA, US
- x 22
Re: The Boost issue (again)
*pours withering scorn all over pianoman because he seems to want it badly*
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: The Boost issue (again)
Some people believe that using it will make it easier to do true cross-platform programming.pianoman wrote:So why does ANYONE use MinGW? No wonder most libraries don't care about MinGW. Shucks, I knew I could count on you guys in the Ogre community. (I hope you're not still scorning me...)
I think it's a bit misguided.
If you use good compilers and good tools, and cross-platform libraries (like Ogre), you can't go wrong.
Do yourself a favour and use the best tools you can get.
Which is why it's recommended to use VC on Windows and GCC on Linux. Which is what the (non-misguided) majority do.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- steven
- Gnoll
- Posts: 657
- Joined: Mon Feb 28, 2005 1:53 pm
- Location: Australia - Canberra (ex - Switzerland - Geneva)
- Contact:
Re: The Boost issue (again)
Here is gcc 4.4.0 for mingw with installer: http://www.tdragon.net/recentgcc/CABAListic wrote:Yeah, MinGW lost a lot of its appeal ever since they started to fall behind the current GCC releases. I mean, MinGW is still stuck with GCC 3.4.5, and let's face it, that version is just not good enough anymore. There is some alpha release of a GCC 4 version, but that download is some months old. I sure hope they catch up some time soon!
You can also look here http://forums.codeblocks.org/index.php/ ... 508.0.html
Btw you should check regularly those links as he often makes newer releases.
This could be the reason of mingw old version:
TDM-GCC is not formally affiliated with or endorsed by the MinGW project (although several MinGW team members make use of it
Last edited by steven on Fri May 08, 2009 5:04 am, edited 3 times in total.
- steven
- Gnoll
- Posts: 657
- Joined: Mon Feb 28, 2005 1:53 pm
- Location: Australia - Canberra (ex - Switzerland - Geneva)
- Contact:
Re: The Boost issue (again)
About the boost - mingw issue I recommend the DIY approach.
I wouldn't trust the boost lib they provide (too many ways to compile boost)
You only need to compile boost once then you will have a working version.
I wouldn't trust the boost lib they provide (too many ways to compile boost)
You only need to compile boost once then you will have a working version.
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: The Boost issue (again)
MinGW is useful if you want to test gcc compatibility and don't have a Linux or Mac machine handy. VC is a wonderful IDE but the compiler still has a number of foibles (although it's getting better) so it's nice to be able to prove your code is a bit more standards compliant. But I wouldn't use it as my primary development environment even if you paid me, VC is much more productive, the binaries are smaller, debugging is great. I do most of my gcc testing via XCode now anyway, which at least has a good debugger (ie it wraps gdb better than most) and is quite nice to use (but not as nice as VC & VAX).
- :wumpus:
- OGRE Retired Team Member
- Posts: 3067
- Joined: Tue Feb 10, 2004 12:53 pm
- Location: The Netherlands
- x 1
Re: The Boost issue (again)
I like boost, I've used it in a few projects and it provides a great utility library.sinbad wrote: Thoughts? I hesitate to change the previous stance just because I want to use Boost more widely now, but maybe others feel now is a good time anyway.
But I'm not sure that requiring it as dependency for Ogre3D is a good idea, Boost is very large and also slows down compilation times enormously (especially the more esoteric parts) in my experience as nearly all the code is contained in C++ template meta programming classes in .h files.
Using only the TR1 subset might be a good compromise. I believe that is scheduled to be included in the C++ standard some day, anyway.
- xavier
- OGRE Retired Moderator
- Posts: 9481
- Joined: Fri Feb 18, 2005 2:03 am
- Location: Dublin, CA, US
- x 22
Re: The Boost issue (again)
WUMPUS!!!!
*rubs eyes to make sure*
*yep, it's really him*
Long time no hear!
Next thing you know, nfz will be making posts, hanging on in IRC and contributing code again.
*rubs eyes to make sure*
*yep, it's really him*
Long time no hear!
Next thing you know, nfz will be making posts, hanging on in IRC and contributing code again.
- :wumpus:
- OGRE Retired Team Member
- Posts: 3067
- Joined: Tue Feb 10, 2004 12:53 pm
- Location: The Netherlands
- x 1
Re: The Boost issue (again)
hey xavier!! yes, it's really me
before you know, temas and mental will start posting again
before you know, temas and mental will start posting again
- Kencho
- OGRE Retired Moderator
- Posts: 4011
- Joined: Fri Sep 19, 2003 6:28 pm
- Location: Burgos, Spain
- x 2
- Contact:
- stealth977
- Gnoll
- Posts: 638
- Joined: Mon Dec 15, 2008 6:14 pm
- Location: Istanbul, Turkey
- x 42
Re: The Boost issue (again)
Well, wanted to share my 2 cents:
Boost is a nice library suitable for many projects, but:
- If it is just going to be used for its threads, wouldnt it be easier to port only that part over to OGRE and get rid of dependency?
- The boost::bind, boost::function can easily be replaced with easy to implement and much faster Fast Delegates?
- The boost::signal is being discussed on many forums and everyone agrees that it is way slower than it should be, it is also very much possible to create an OgreSignal template using Fast Delegates again (said to be 80x faster than boost::signal when both are in debug mode and probably still a few times more faster than boost::signal when both are in release mode)
- I implemented boost::bind,function,signal replacement class in Ogitor and its only a 344 lines header file...Wouldnt be much harder to create one supplying all functionality OGRE needs...
Also removing the boost dependencies means that OgrePaging, OgreTerrain and OgreProperty can be easily copied to v1.6.x branch, people would be asking for it when especially OgrePaging and OgreTerrain is complete, considering that Ogre v.1.8 will be available in sometime 2010...
ismail,
Boost is a nice library suitable for many projects, but:
- If it is just going to be used for its threads, wouldnt it be easier to port only that part over to OGRE and get rid of dependency?
- The boost::bind, boost::function can easily be replaced with easy to implement and much faster Fast Delegates?
- The boost::signal is being discussed on many forums and everyone agrees that it is way slower than it should be, it is also very much possible to create an OgreSignal template using Fast Delegates again (said to be 80x faster than boost::signal when both are in debug mode and probably still a few times more faster than boost::signal when both are in release mode)
- I implemented boost::bind,function,signal replacement class in Ogitor and its only a 344 lines header file...Wouldnt be much harder to create one supplying all functionality OGRE needs...
Also removing the boost dependencies means that OgrePaging, OgreTerrain and OgreProperty can be easily copied to v1.6.x branch, people would be asking for it when especially OgrePaging and OgreTerrain is complete, considering that Ogre v.1.8 will be available in sometime 2010...
ismail,
Ismail TARIM
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: The Boost issue (again)
Yeah, I know it's possible to re-implement the threads subset. Or, even just try to pull it out. But, this is all time that could be spent on other things
Right now, we only use boost::thread and optionally boost::range, with boost::bind optional. Boost is no impediment to 1.6 backporting, we've always used Boost for threading for several years.
I personally think FastDelegates is good but a dead-end. boost::bind is going into the standard, and since boost 1.34 the performance difference isn't very much - the idea that it's massively more efficient than boost::function is largely historical now. We don't rely on signals yet, but my experience with it 'in the wild' is that it's fast enough for the places I used it (editors), plus there's now signals2 which solves the thread safety issue. But, I don't see myself requiring signals in the future.
Often I think too many people roll their own code when they don't need to. I prefer to use the longer-term approach of going with proven, standardised solutions, both because it saves time & improves stability early on, and because I don't want to be stuck maintaining a custom version. Frankly, given limited time resources for Ogre I have far more important things to do than to rewrite common subsystems that have already been implemented by others many times over.
I want to add support for using something other than Boost, but frankly, I have a *lot* of other things I could be doing with that time. If anyone feels strongly enough about this, then they should contribute (for example) a thread wrapper which works equally well with the users choice of threading library (boost, POCO, TBB, posix). In a perfect world I'd love to do this, but frankly I can't see it featuring on the top 10 of my priority list any time soon.
Right now, we only use boost::thread and optionally boost::range, with boost::bind optional. Boost is no impediment to 1.6 backporting, we've always used Boost for threading for several years.
I personally think FastDelegates is good but a dead-end. boost::bind is going into the standard, and since boost 1.34 the performance difference isn't very much - the idea that it's massively more efficient than boost::function is largely historical now. We don't rely on signals yet, but my experience with it 'in the wild' is that it's fast enough for the places I used it (editors), plus there's now signals2 which solves the thread safety issue. But, I don't see myself requiring signals in the future.
Often I think too many people roll their own code when they don't need to. I prefer to use the longer-term approach of going with proven, standardised solutions, both because it saves time & improves stability early on, and because I don't want to be stuck maintaining a custom version. Frankly, given limited time resources for Ogre I have far more important things to do than to rewrite common subsystems that have already been implemented by others many times over.
I want to add support for using something other than Boost, but frankly, I have a *lot* of other things I could be doing with that time. If anyone feels strongly enough about this, then they should contribute (for example) a thread wrapper which works equally well with the users choice of threading library (boost, POCO, TBB, posix). In a perfect world I'd love to do this, but frankly I can't see it featuring on the top 10 of my priority list any time soon.
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: The Boost issue (again)
Nice seeing you !:wumpus: wrote:yes, it's really me
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- xavier
- OGRE Retired Moderator
- Posts: 9481
- Joined: Fri Feb 18, 2005 2:03 am
- Location: Dublin, CA, US
- x 22
Re: The Boost issue (again)
I still think that Ogre needs to worry less about "threads" and more about "tasks". Explicit thread management itself is becoming "largely historical" now, and Ogre is "falling behind the curve" as the trend in hardware moves towards N cores. Limiting Ogre to a very small fixed number of self-managed threads is a losing proposition long-term.sinbad wrote: I want to add support for using something other than Boost, but frankly, I have a *lot* of other things I could be doing with that time. If anyone feels strongly enough about this, then they should contribute (for example) a thread wrapper which works equally well with the users choice of threading library (boost, POCO, TBB, posix). In a perfect world I'd love to do this, but frankly I can't see it featuring on the top 10 of my priority list any time soon.
IMO if anyone works on Ogre's concurrency model, they should be thinking about how to fit Ogre into a task-based processing model, and less about which thread-abstraction library or approach is "best".
- Wolfmanfx
- OGRE Team Member
- Posts: 1525
- Joined: Fri Feb 03, 2006 10:37 pm
- Location: Austria - Leoben
- x 99
- Contact:
Re: The Boost issue (again)
But sinbad already introduced a task system with the new terrain system and you can also provide your own task system which handle the tasks.
- xavier
- OGRE Retired Moderator
- Posts: 9481
- Joined: Fri Feb 18, 2005 2:03 am
- Location: Dublin, CA, US
- x 22
Re: The Boost issue (again)
I don't find this mentioned anywhere -- where do you see this?Wolfmanfx wrote:But sinbad already introduced a task system with the new terrain system and you can also provide your own task system which handle the tasks.
Besides, how does this apply to inherently data-parallel processing such as for animation or particle systems? Since the paging system is provided as a plugin, you can hardly make core features or other plugins depend on it.
- Karan
- Halfling
- Posts: 62
- Joined: Wed Sep 17, 2008 1:59 pm
- Location: Berlin, Germany
Re: The Boost issue (again)
It's mentioned here: http://www.ogre3d.org/forums/viewtopic.php?f=4&t=50160
- xavier
- OGRE Retired Moderator
- Posts: 9481
- Joined: Fri Feb 18, 2005 2:03 am
- Location: Dublin, CA, US
- x 22
Re: The Boost issue (again)
That would explain why I didn't see it in the paging thread, thanks.
I've posted a relevant question in that thread.
I've posted a relevant question in that thread.
- :wumpus:
- OGRE Retired Team Member
- Posts: 3067
- Joined: Tue Feb 10, 2004 12:53 pm
- Location: The Netherlands
- x 1
Re: The Boost issue (again)
Still, a task scheduler sits on top of a thread abstraction, so either way you will need onexavier wrote:sinbad wrote: I still think that Ogre needs to worry less about "threads" and more about "tasks". Explicit thread management itself is becoming "largely historical" now, and Ogre is "falling behind the curve" as the trend in hardware moves towards N cores. Limiting Ogre to a very small fixed number of self-managed threads is a losing proposition long-term.
- xavier
- OGRE Retired Moderator
- Posts: 9481
- Joined: Fri Feb 18, 2005 2:03 am
- Location: Dublin, CA, US
- x 22
Re: The Boost issue (again)
Which is why I recommended TBB in the other thread -- may as well let Intel deal with the low-level heavy lifting on all fronts there...
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: The Boost issue (again)
Yeah, and I've explained in that thread why I chose not to use it.
The task-processing model is already done and is working in trunk anyway, check out WorkQueue. So we're not 'behind the curve' anymore All that task management needs is the lower-level thread support to underpin it, and worker threads can be created by Ogre or controlled / shared externally.
The task-processing model is already done and is working in trunk anyway, check out WorkQueue. So we're not 'behind the curve' anymore All that task management needs is the lower-level thread support to underpin it, and worker threads can be created by Ogre or controlled / shared externally.
- Moohasha
- Gnoll
- Posts: 672
- Joined: Fri Dec 07, 2007 7:37 pm
- x 8
Re: The Boost issue (again)
Event though I'm not a developer, I'm gonna throw my $0.02 in. I like the idea of making boost a dependency if:
1) Like others have said, you only pull out the parts of boost that you need (thread, bind, etc...), and
2) You can find a way, if possible, to put all boost dependencies in the source and have none in the headers.
The reason for 1) is that in my experience, boost is a huge dependency. I think once I compiled it, the entire folder (including object files), was over 1 GB. For people like me who don't use boost in every project, that's kinda annoying.
And the reason for 2) is that having boost exposed in the headers means that any project I'm working on which needs the Ogre build with multi-threading enabled must also include and link in boost. So anytime I move my code to another machine in our development lab, either for testing or because someone else is working on it, I have to move boost with it. Probably not a big deal if it's now a dependency, but it's still annoying that the boost dependency infects whatever I'm using Ogre in. It's like GPL!
Also, this would make it easier to move away from having to compile Ogre with threading enabled/disabled, and could make it a method that you enable/disable within the same library at runtime (during startup). Because correct me if I'm wrong, but one reason the threading stuff is macro-guarded is because it depends on boost?
1) Like others have said, you only pull out the parts of boost that you need (thread, bind, etc...), and
2) You can find a way, if possible, to put all boost dependencies in the source and have none in the headers.
The reason for 1) is that in my experience, boost is a huge dependency. I think once I compiled it, the entire folder (including object files), was over 1 GB. For people like me who don't use boost in every project, that's kinda annoying.
And the reason for 2) is that having boost exposed in the headers means that any project I'm working on which needs the Ogre build with multi-threading enabled must also include and link in boost. So anytime I move my code to another machine in our development lab, either for testing or because someone else is working on it, I have to move boost with it. Probably not a big deal if it's now a dependency, but it's still annoying that the boost dependency infects whatever I'm using Ogre in. It's like GPL!
Also, this would make it easier to move away from having to compile Ogre with threading enabled/disabled, and could make it a method that you enable/disable within the same library at runtime (during startup). Because correct me if I'm wrong, but one reason the threading stuff is macro-guarded is because it depends on boost?
Black holes are where God divided by 0
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: The Boost issue (again)
I will most likely look at providing a cut-down precompiled version of Boost when we come to release (it's all headers anyway, except for boost-thread), if I haven't had time to provide other options (or no-one else has volunteered to provide them - and I've observed that people can be very vocal when protesting but often go quiet when I ask for some assistance in addressing their concerns ). As things stand, you still don't have to have Boost to build Ogre, it's just that if you do, you get a bunch of benefits (threading, boost::range support, optional property lib, etc). With Cmake now, if it finds Boost it automatically enables this stuff for you, otherwise it's just not there.
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Re: The Boost issue (again)
It's easy enough to fish out the parts of Boost you need - I can't remember the name of the tool, but Boost has a tool like that - IIRC that's what Walaber used to make OgreNewt's shaved Boost copy.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.