Learn From my Fail

[viejodani]

as you code for either games, libraries of software, there are certain mistakes we commit that affect the performance or behavior of the product. While there is a thread about Irrlicht glitches, I wanted a more general list of mistakes that we want to share to fellow developers so they don't make those same mistakes.

My first mistake:
multi-threading is a double edge sword, don't think that your game will be faster if you use a lot of threads, you will have serious problems with weird behaviors or synchronization problems.

My second mistake:
Comment your code after the game works. I forgot many times what a variable or function was used for and on editing the code I screwed up a lot

[ChaiRuiPeng]

My second mistake:
Comment your code after the game works. I forgot many times what a variable or function was used for and on editing the code I screwed up a lot

thats common since

[serengeor]

My first mistake:
multi-threading is a double edge sword, don't think that your game will be faster if you use a lot of threads, you will have serious problems with weird behaviors or synchronization problems.

I tried multi-threading too(long time ago), but I find that it is unnecessary for what I am actually planning.

My second mistake:
Comment your code after the game works. I forgot many times what a variable or function was used for and on editing the code I screwed up a lot.

I usually pick good names for functions and variables, so when I look at them I remember what it was meant for

[Radikalizm]

as you code for either games, libraries of software, there are certain mistakes we commit that affect the performance or behavior of the product. While there is a thread about Irrlicht glitches, I wanted a more general list of mistakes that we want to share to fellow developers so they don't make those same mistakes.

My first mistake:
multi-threading is a double edge sword, don't think that your game will be faster if you use a lot of threads, you will have serious problems with weird behaviors or synchronization problems.

My second mistake:
Comment your code after the game works. I forgot many times what a variable or function was used for and on editing the code I screwed up a lot

I have found and implemented a very nice multithreading model myself if I may say so, I made a thread about it a while ago, it's a work-stealing task-based system
Multithreading in real-time applications is just a matter of wisely choosing which parts of your program are suited for parallelization and being able to neatly package those components and send them through a scheduler without them interfering with the rest of the program

And about commenting, I think we all have made that mistake atleast once in our programming careers, and it's just something which should become a second nature
I mostly find that not commenting code or thinking comments are not needed is a result of not planning out your code too well which in itself will ruin any large project after a while

I usually pick good names for functions and variables, so when I look at them I remember what it was meant for

This works on a small scale, but once your project is in development for a long time or once it becomes bigger than just a couple of files/classes it gets harder to find names which describe the complete purpose of certain functions
Also, if other people work with your code or if you haven't looked at a certain piece of code for a while it's always nice to have a reference guide on what kind of inputs the function expects and what kind of output you can expect (DbC-style)

[Adler1337]

My first mistake:
multi-threading is a double edge sword, don't think that your game will be faster if you use a lot of threads, you will have serious problems with weird behaviors or synchronization problems.

I never tried multi-threading. I never found it to be a necessity and after hearing a lot of horror stories I'm not sure if I would ever implement it.

My second mistake:
Comment your code after the game works. I forgot many times what a variable or function was used for and on editing the code I screwed up a lot

thats common since

No, that's common sense

[ChaiRuiPeng]

My first mistake:
multi-threading is a double edge sword, don't think that your game will be faster if you use a lot of threads, you will have serious problems with weird behaviors or synchronization problems.

I never tried multi-threading. I never found it to be a necessity and after hearing a lot of horror stories I'm not sure if I would ever implement it.

My second mistake:
Comment your code after the game works. I forgot many times what a variable or function was used for and on editing the code I screwed up a lot

thats common since

No, that's common sense

[serengeor]

I usually pick good names for functions and variables, so when I look at them I remember what it was meant for

This works on a small scale, but once your project is in development for a long time or once it becomes bigger than just a couple of files/classes it gets harder to find names which describe the complete purpose of certain functions
Also, if other people work with your code or if you haven't looked at a certain piece of code for a while it's always nice to have a reference guide on what kind of inputs the function expects and what kind of output you can expect (DbC-style)

It worked out great so far, and I'm a one man team, so no worries

[Brainsaw]

as you code for either games, libraries of software, there are certain mistakes we commit that affect the performance or behavior of the product. While there is a thread about Irrlicht glitches, I wanted a more general list of mistakes that we want to share to fellow developers so they don't make those same mistakes.

I got some experience in programming, so I guess I'll add a few comments

My first mistake:
multi-threading is a double edge sword, don't think that your game will be faster if you use a lot of threads, you will have serious problems with weird behaviors or synchronization problems.

Satan himself created multithreading. I'm sure about that. The first important thing is to *really* know what you're doing when trying that. Here at work I work on some projects that just spawn threads for everything, and this slows them down quite a bit. But I do some planning to make a multithreaded version of my IrrOde wrapper, but that would just be 2 threads, one for Irrlicht, one for ODE (maybe a third one for networking), but before I do that I have to get a stable threadsafe messagequeue finished.

My second mistake:
Comment your code after the game works. I forgot many times what a variable or function was used for and on editing the code I screwed up a lot

[megalomania activated]
I don't need to comment my code. I mean ... good code (e.g. mine) doesn't need any documentation, it documents itself. Moreover my code is so damn good that even the assembly code generated by any compiler is self documenting. I just need to take a small look at it and know what's going on.
[megalomania deactivated]



Just kidding ... It is definetely important to have at least little comments, if you don't touch your code for like 6 months and want to change anything you'll be in big trouble otherwise. Or, read in a signature round here:

Software documentation is like sex. If it's good you want more, if it's bad it's better than nothing.

[Sylence]

Yep I made this mistake as well. When you write your code everything seems perfectly logical and self documenting but when you look at it some months later you're always like "damn what was this idiot thinking when he wrote this? duh... that was me"

It doesn't matter if you use good names for variables, classes, and methods. If you didn't touched the code for some time it doesn't really help if you know what is done there but you don't know how and why

P.S.:
My signature got quoted. Yeah ^^

[serengeor]

For me good names does the job, maybe its because I'm working on only one project atm.
I don't have anything against comments, sometimes I use them, but mostly they are to remind me if something needs fixing

[REDDemon]

Keep low number of WIP.

progress in each WIP is like N^(-N) where N is the number of WIP.

[Brainsaw]

P.S.:
My signature got quoted. Yeah ^^

I knew it was around here somewhere. It's about the best signature I've seen till now (together with Rogerborg's "everytime someone learns to use a debugger an angel gets wings").

[hendu]

Multithreading is a *very* hard topic. So much so that unless you really need it, don't bother is the common recommendation

There is a free book about the issues, still somewhat in progress and with a fairly steep learning curve (comes with the nature of parallel processing), but after reading it one can certainly appreciate the magnitude of parallel things.

http://www.kernel.org/pub/linux/kernel/ ... /perfbook/


Me? As recommended in the book, I won't bother unless I explicitly need it. If it's 2x the programmer time for 1.1x speedup, why bother?

Also, the issue should be in the embarassingly parallel class for it to scale at all nicely.

[Radikalizm]

I'm going to leave this here for anyone interested in implementing multithreading:
http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=42488

This system scales to the amount of CPU's available in your machine, is very manageable, and gives very nice results in dynamic scenes (don't bother with very simple scenes, it'll just create overhead)

The nice thing about this is that you can set up tasks/jobs with a function to split itself into multiple jobs/tasks, this way when a worker thread goes idle it can check out the task queue of another thread to see if it can split a queued task and take over one part of it. If it can't, it just steals the complete task from the queue and executes it itself, creating a continuous even spread of tasks over all threads

[viejodani]

That was a very good article, Radikalizm.

I have used multi-threading now when I have to perform AI calculations. I'm developing my own AI engine and using threads has made it very fast to deliver a good result. I use a right amount and so far it has been doing great.
I will use the ideas from this article sometime. I limit myself to perform strong calculations on separate threads to keep good FPS

About code commenting. It's true that having good variable and class names can do the trick. However, it's not the full solution. The problem comes when you write the functions. I learned that a good comment not only helps you remember whet the function does. But when you have a fellow programmer, both can be on the same wave. and you save time. So I comment code as I program, then I edit the comments to make it more professional.