Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I have been a computer-fanatic for almost a decade now. I've always loved and wondered how computers work, even from the purest, lowest hardware level to the very smallest pixel on the screen, and all the software around that.

That seems to be my problem though ... as I try to write code (I'm pretty fluent at C++) I always sit there enormous amounts of time in front of a text-editor wondering how every line, statement, datum, function, etc. will correspond to every Assembly and machine instruction performed to do absolutely everything necessary for the kernel to allocate memory to run my compiled program, and all of the other hardware being used as well.

For example ... I would write cout << "Before memory changed" << endl; and run the debugger to get the Assembly for this, and then try and reverse disassemble the Assembly to machine code based on my ISA, and then research every .dll, library file, linked library, linking process, linker source code of the program, the make file, the kernel I'm using's steps of processing this compilation, the hardware's part aside from the processor (e.g. video card, sound card, chipset, cache latency, byte-sized registers, calling convention use, DDR3 RAM and disk drive, filesystem functioning and so many other things).

Am I going about programming wrong? I mean I feel I should know everything that goes on underneath English syntax on a computer program.

But the problem is that the more I research every little thing the less I actually accomplish at all. I can never finish anything because of this mentality, yet I feel compelled to know everything... what should I do?

share|improve this question

closed as not constructive by Byte56, Nathan Reed, Laurent Couvidou, Josh Petrie, doppelgreener Nov 13 '12 at 5:04

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

Eh... wut? What is the relation with game development? –  nathan Nov 10 '12 at 17:11
Like many things in life, it's a balance. Find the balance that gets work done and keeps you informed. –  Byte56 Nov 10 '12 at 17:20
one simply cannot know everything... sorry –  Edin M. Nov 10 '12 at 17:26
Follow your passion, if its fun for you. You will find your way, dont worry, just enjoy it. –  Maik Semder Nov 10 '12 at 18:38
Search for a Hackerspace in your area. Chances are high you find like-minded people there. –  Maik Semder Nov 10 '12 at 18:54

3 Answers 3

In general, yes, you should indeed have a decent understanding of the hardware, the OS, how DLLs work, and other low-level details. As a C++ programmer, there will even be (rare) occasions where you need to inspect a stack, follow base pointers, and reconstruct a proper stack trace when the stack is so screwed that the debugger can't do it for you.

That said, in specific to what you've asked, you are definitely massively overdoing it in one sense. You don't need to worry about specific assembly output of code. In fact, I'll guarantee that your understanding of ideal assembly output is wrong, as modern CPUs are ridiculously complex and obtaining ideal efficiency has less to do with the specific assembly output of a line of code and more to do with whole-program transformations. Turn on the right level of optimization and you won't even be able to find or identify individual lines of code in the generated assembly in many cases. Humans are bad at anything besides micro-optimizations (short sequences of assembly) and macro-optimizations (algorithmic choices): everything in between is usually better done by the compiler than you, and even many micro-optimizations are better handled by the compiler.

It is useful to know what the compiler does. There are ways of writing code that lets the compiler do its job very well, and ways to write code that totally defeat the compiler's algorithms.

It is useful to know how the CPU (or GPU) work internally. There are many ways to write assembly that looks fast but which performs like crap. If you don't understand cache hierarchies, the way DRAM works, CPU instruction pipelines and data dependencies, GPU core block behavior, and GPU texture memory access patterns, then you are utterly incapable of making intelligent decisions about optimizing modern real-world programs. That said, know these in terms of whole algorithms, NOT individual lines of code.

Knowing the exact assembly output of C++ code is just not valuable. Knowing how to optimize code comes from knowing what lets the compiler work, knowing what general patterns to avoid or prefer for target hardware, and how to identify and fix measured performance problems.

And that's the last bit of optimization wisdom I have for you. PROFILE YOUR CODE. If you are making optimization decisions based on assembly output rather than actual metrics and performance data, you are not only wasting tons of your time, you are actively defeating yourself. To be blunt, optimization without profiled data verifying the optimization is pure incompetence. The majority of the time you do that, in my experience, you will be introducing performance pessimizations rather than optimizations. You might think you know what an individual line of code does all the way down to the hardware, but if you can't think about how the entire algorithm works, you lose. There are many cases where you can micro-optimize one small piece to the detriment of the whole. And you as a human being are not capable of understanding the whole down to the hardware level you are talking about, especially when you consider all the smarts in the hardware that "undermines" the assembles (out of order CPUs, DRAM row banks, cache layers, and a bazillion similar things). You MUST rely on profile data and larger metrics, not per-line performance tuning.

Again, I have very directly seen cases where optimizing one line really did make the whole algorithm slower. It was non-intuitive, had nothing to so with how the one lone executed, and everything to do with how that line defeated the ability for the compiler and CPU smarts to handle the larger body of code.

In reference to your problems with getting things done, that's a sign that you are failing as a game developer due to your preoccupation with performance. The performance of your game is utterly irrelevant compared to your performance as a game developer. Optimize for speed of design and content iteration first, and speed of engine execution second. The fastest game engine in the world that can't be used to make a real game in reasonable time periods is utterly worthless. Look for instance at how unpopular Carmack's engines have become (they haven't been licensed by more than a handful of companies since Quake 3, since they're barely useful for anything besides the one game they're made for) or how every major AAA developer used to have to spend so much time rewriting large parts of Unreal in order to make it work for non-FPS games (it's a lot better these days, but it was pretty bad back when Unreal 3 was new).

share|improve this answer

This seems a bit like obsessive / compulsive behaviour and I would try to avoid this as much as you can. If you want a future job optimizing performance on games etc. I'd say go for it.

It really depends on what you want with you future. Do you like designing stuff that's epicly optimized, or do you want to quickly produce lots of games etc.

I don't think your question has a really conclusive answer, but I'd like to point out most companies look at what your work output is. Working to slow could get an issue eventhough you know exactly what's going on beneath the hood.

share|improve this answer

I can say from my own experience: the more you know, the better. But:

I used to be a (more or less) successful programmer without knowing all the details about how stuff worked. I even wrote C++ without understanding why I had to write header files and source files, or even what they were used for. I just followed the rules, and it often worked.

But as I went on, I stumbled upon problems I was not able to resolve without understanding the problem itself. Now I can say I have a pretty good understanding of what the machine in front of me does and why it does it. This makes debugging etc. a lot easier and programming a lot faster.

I still don't know anything about assembler, I couldn't really interpret a line of it (yes, I know it moves memory around and not much more, but I can't read or write it). But that is not the point. I know basically what the languages I use (e.g. C++) will be compiled into, and how instructions are being translated. The hardest part was probably understanding memory management (pointers, references, etc.), but now I resolve most segfaults within seconds.

I hope this helps you to find your way through this huge amount of stuff you could learn, and you probably will learn while working with it. Best of luck!

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.