Code center > Darwinbots3
Release date
bacillus:
I had a look today at the DB3 code. I was struck by the simplicity of the DNA parser, I expected a huge chunk of unreadable code, not a huge chunk of readable one. I still haven't figured out how to commit anything, not that I have time with exams so close and the F1 league to chip away at. Although I would make the suggestion to move the whole thing to Google Code if it's not too cumbersome.
Numsgil:
I try my best I'm rather happy with the DNA code atm, though it still needs some features to be implemented, and I skipped writing tests for the top level code. And I sort of went overboard with exceptions in the parsing code...
To commit you'd need SVN access. anonymous access is read only. I can set up an account if you're really interested. Same goes for anyone. It's all version controlled, so if you screw things up I'll just revert it
I've heard that google code isn't quite up to snuff just yet. Or that's what my friend at work said. I might look in to it and see if it would work better than my private SVN for this use.
bacillus:
Google Code is probably so good because it's public; no-one can sabotage your work permanently unless they were an evil hypnotist with way too much spare time, and you sometimes end up drawing out some brilliant ideas from some random guy who drops in a gem of code.
Trafalgar:
--- Quote from: Numsgil ---What I like about C# are things like run time reflection (ie: easily determining the type of an object at run time.
--- End quote ---
Side note: run time reflection has poor performance. Delegates also have poor performance. But, yeah, don't worry about that much.
There are cases where you can write code which is faster without being less readable, and if you know about those you can take them into account when designing something. For example, if you're planning something which you would normally do (numFoos % maxFoos) (modulus), you can swap the slow modulus operation for an extremely fast & operation if numFoos is always positive and maxFoos is (2^n), where n is any positive number. You would & it by 1 less than you would have %'d it by. (numFoos % 4) would become (numFoos & 3), for example.
E.G. Here's an example in javascript (I just copied this right out of what I'm working on at the moment).
--- Code: ---var blankSubEntry = (lastWritten[(lastWrittenStart+matches)&maxMatches]==="");
if (hash == lastWritten[(lastWrittenStart+matches)&maxMatches] || blankSubEntry) {
--- End code ---
Now normally you might say "well I should store (lastWrittenStart+matches)&maxMatches into a variable and then refer to that" - and that's fine. But hopefully the compiler should be smart enough (but not necessarily with javascript...) to optimize those so that'll only be calculated once anyways. Even if it doesn't, and you do that 5 times, it should still be faster than doing it with % once. (% takes 30-40 clock cycles, IIRC, and & takes about 0.5, in a pentium 4*)
* = I'm oversimplifying how that works. It's actually more complicated than that, and depends on what other operations are being done at the time, and what's going to be done after it, and I don't have a clue how it has changed after the pentium 4 or with AMD CPUs, etc.
So, things I usually do:
1. Prefer & instead of %, and choose power-of-2 sizes for things which will be using it (otherwise we can't use &).
2. For distance checks, omit the sqrt, and premultiply whatever we're going to be comparing against. You can calculate xdist*xdist + ydist*ydist and compare it to somedist*somedist to determine if the distance is <, =, or > than somedist. You can't determine how far apart they are, though. (Sqrt is slow)
3. If doing foo squared, replace with foo*foo (an optimizing compiler might already do this)
4. If doing foo * 2, replace with foo+foo (an optimizing compiler might already do this). Since multiplication (30ish cycles?) is much slower than addition (.5 cycles), you could even do foo+foo+foo+foo if you really wanted to, except that foo << 2 would also work there and would probably be faster.
5. When designing things that will be multiplied or divided by a number, prefer designing them so that you can use power-of-two multipliers/divisors. The compiler might be able to optimize multiplication/division by a constant which is a power of 2 to use << and >> instead, which is faster than multiplication, or you can do it yourself.
I tend to code in an already-optimized-but-readable style, but leave the really heavy optimizations to the compiler (especially with c#). Most of what I do are things the compiler can't or wouldn't be likely to - e.g. it can't change the number of terrain types from 7 to 8 and change the % to & and such without breaking your program, but you can design it better instead.
(In some languages I tend to optimize less. For instance, javascript for firefox extensions. I once tried to determine what was the bottleneck in an extension of mine which ran rather slow on many webpages, only to track almost all of the CPU use into a part of firefox's javascript math crap that I couldn't do anything about. That is, the extension checks the HTML and CSS for a page and reverses colors to change dark-on-light pages to light-on-dark pages. The problem is that for some reason firefox's JS math was terribly slow, and the string to int stuff and vice versa too (which were pretty much required for the extension to work and be useful).)
Numsgil:
--- Quote from: Trafalgar ---1. Prefer & instead of %, and choose power-of-2 sizes for things which will be using it (otherwise we can't use &).
--- End quote ---
That's specifically what I'm avoiding. You see, it just doesn't matter if there's a 100x faster way of doing something if that function only gets called 3 times a second every other Tuesday. Code for people and algorithms 99% of the time. Then profile, identify hot spots, and refactor/optimize them away. You might know how your code works, but it's going to be Greek to the guy that maintains it after you.
Once you crack out the profiler and are able to say something like "Function FooBar is taking 5ms per call. Reduce that down to 2ms per call", you can iteratively refactor your code just for that function to achieve the desired performance.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version