Threading performance hit
BlitzMax Forums/BlitzMax Programming/Threading performance hit
| ||
| After compiling my game as a threaded app it runs very poorly (jerky). I didn't actually create any threads in the code at all, just changed the compiling option. I'm using BlitzMax 1.33, not SVN. I read somewhere that the threaded GC slows things down. Is this still the case? I don't actually want to run any threads during gameplay, just for checking online gameservers during menu screens. Is there anything I can do to get my performance back whilst keeping threading? |
| ||
| Wait until the next version which may (or may not) be a bit better. |
| ||
| What that means also is it's showing up the areas of your app that are not constructed well with garbage collection in mind. Before, you got by with the collector working differently, now you need to optimize for the new one. |
| ||
| Yeah, I basically let the GC do it's own thing. |
| ||
| Can you suspend the Threaded GC like the non-threaded one? If you suspend it and not turn it on, does it run as fast as if you compiled with the normal GC? I know you can't run like that normally, as the memory usage will just climb, but I am curious if there is something else going on in threaded mode that makes it run slower as well? |
| ||
| You can GCSuspend as normal, but as you say, eventually there's going to be an increase in memory usage dependong on what you're doing. |
| ||
| You may also consider manually garbage collecting more often, which may result in less chance of jumping caused by the GC collecting lots of objects at one time. |
| ||
| OK, so you can suspend the GC. Let's say you took the first posters app and compiled it threaded but with the GC suspended. Would it run as fast as a non-threaded compile with GC suspended? I am just curious if maybe there isn't some other performance hit as well as the GC one. |
| ||
| Well, I just compiled one of my ifsoGUI example apps with threading on and off and with GCSuspend and not, and there was no change in performance for any of them. Hmmm... |
| ||
| I tried a simple rotating cube in Leadwerks Engine and found that with a threaded app... with GCSetMode(1) 'auto' frames per second were 42fps with GCSetMode(2) 'manual' and importantly no call to GCCollect() in the loop fps was still 42fps Compiled without the threading option I always get 222fps. The only way I could get fps=222 in the threaded mode was to use GCSuspend() before the loop and GCResume()+GCCollect() after. Throughout the loop GCMemAlloced() always returned 0. It seems there is a huge performance hit in threaded mode just with the GC being active even if no call is made to GCCollect(). As it is you are better suspending the GC in areas of the program where no garbage is being created and resuming after that area is left. Or you could suspend the GC and only resume/collect when GCMemAlloced() returns a high enough value for you to bother about. |
| ||
| You Bmax gurus out there: Is it possible to mitigate this by compiling a threaded DLL, but having a non-threaded main program? Example: Let's say you have a loggning/recording system in a game. You might want to thread the actual writing of the logfile to disk so it won't in any way affect main-loop performance. Can it be done to write a dll (with all synchronization bells and whistles) that can accept a call like logMsg(msg:String) from the main-program, but in the background it places logged lines in a list that are slowly written to disk by an background thread as necessary? |
| ||
| Why even use threaded apps in Blitzmax games? Seriously, I just don't get it except to brag that your game uses it? |
| ||
| because on multi-core processors you can get a lot more done in a shorter time span... a non-threaded app can't utilize any parallel processing at all, only time share... I'm hoping to have my network stuff running in a thread among other things. |
| ||
| Why even use threaded apps in Blitzmax games? So how heavy stuff can you possibly add to the mainloop without getting visible breaks? everything above 100ms(50 even?) will be very visible and ugly. If you wanna do anything against the filesystem or a database connection it's not a good idea to place it in the mainloop. Many games mitigate this by displaying a "Loading"- screen and loading a full level at a time, but if your game is of any size and you intend to make it seamless (without visible loading), threading could preload resources in the background and make the resources available to the mainthread when the loading is done. (Check the slowload-demo in the thread-demo folder in the bmx1.33, to see it in action) Imho it's not merely a buzzword, but rather something that most developers will find good use for if they add it to their "skill toolbox". |
| ||
| Still seems like something to tinker with for techies. I seriously doubt any shareware/commercial coder writing a game for the pc/mac market using Blitzmax is even remotely thinking of ways to add threading to their game. |
| ||
| I seriously doubt any shareware/commercial coder writing a game for the pc/mac(a) market using Blitzmaxb [...] Note how this sentence could be used (changing a and b) for many techniques that are today mainstream among indies. It could be: * 3D graphics in the early 90s. * Full 3D models for chars (instead of sprites) in the mid 90ties * Shaders just a few years ago. * Realtime pixel-perfect 2D collisions without specific hardware support. etc.etc. As the big software houses release new "top of the line" titles, presenting new features, indies (generally) slowly follow and the techniques become mainstream over time. Threading is now used in most commercial top titles to utilize the additional CPU-cores available on most machines. It's only logical that the indies follow (slowly after) this development too, imho. Besides in many languages (bmx included) the threading is completely optional, so any developer that does not need this can simply just ignore checking the flag in the IDE and just continue live his/her life as it was. Win-Win :-) |
| ||
| @MGE I hate it, when someone is talking about blitzmax as a little indie developer langauage. blitzmax is a hll. i'm sure, if everybody talked like you, MGE, there wont be major titles done with bmax never at all indeed. thats how to kill visions. fortunately, not everyone does. why are you actually using bmax? why would any indie developer need to utilise the graphics card? does any indie developer actually need 3d? and oop.. isnt that something we also dont realy need? (edited to remove harshness) sorry. just a little outraged about this. |
| ||
| Still seems like something to tinker with for techies. As I mentioned in the first thread, I'm trying to add online multiplayer to my racing game New Star GP. The lobby needs to check an sql database on my website every few seconds to see what game servers are available. Without putting this check in a separate thread there is a regular half second pause while it receives the data. Sure, it's not the end of the world but it's not ideal. |
| ||
| If you want it easy, no threads, dbs, and stuff and to just focus on making games by point-and-click, try Game Maker: http://www.yoyogames.com/ BlitzMax on the other hand is a full blown modern OOP-language with a 2D lib. (disclaimer: I'm not affiliated with game maker in any way.) |
| ||
| Without putting this check in a separate thread there is a regular half second pause while it receives the data Why don't you use a non-blocking request to the server? |
| ||
| Whoa, Joseph @ BeAnAge, thats harsh... chill out An indie developer is just basically a single developer... there is no shame in being an indie developers language of choice... Yes, BMax has the ability to produce bigger and better things, and may be the choice of a professional development team in the future, but it would need to mature before that happens. The docs are weak for the moment, and there are still tweaks being done to the language core such as the GC. Glad to see your so passionate about the language, I love it too! but using words like "{edit: removed harshness}" is over the top. Back on topic... Threading is the way of the future... parallel processing is where everything is headed.. there even talking about network based cloud computing as well. So ignoring threaded operations would be a mistake in my mind. indie or not, threaded operations are here and won't be going anywhere. Utilizing the untapped power in multi-cores is an indie developers best friend since we don't have programming teams to concentrate on every little bit of code to best optimize it... IMHO |
| ||
| @mge: sorry. i edited it. @skully: multicore usage is inevitable, indeed. but imo, theres even better, and more powerful ways to utilise multiple cores, than plain multithreading! I was impressed when i read about FBP. Fascinating. Yet have a rough version of an implementation of this in work, with cross-platform shared memory, simple tcp synchronization, and even low-level multicontext-rendering support.. might showcase that within the next 2 weeks. (And.. btw.. its plain bmax^^) |
| ||
| Well, you will still need threading for flow based processing if you want it to utilize more than one core anyway.. otherwise its just time shared monitoring while you wait for "black box's" to finish their transformations. |
   |