The speed will vary depending on the CPU speed but I still need an approximate 'feel' for it.

Calin

------------------
Check my C# libraries

EDIT: On second read, did you mean, for instance, a website with c# benchmarks for some standard snippets of code? If this is true, then you might be trying to prematurely optimize your code. I personally hold to the adage that "premature optimization is the root of all evil"(a close equal with the love of money ).

Programmers (myself) have a natural tendency to waste immense amount of time optimizing things that do not need to be optimized. So, its a good idea to "Write new code well, profile it, rewrite the slowest parts better, repeat until deadline". Some think this is a waste of time--rewriting code, but personally it speeds things up and also produces more fully-functioning builds. One might also include periodic "optimize" milestones where the whole focus is refactoring the program as a whole for speed optimization.

But always use a profiler, because a problem with using benchmarks these days is that optimizing compilers can, and often do give exaggerated timings because the code being evaluated is not in the context of a "real life" program.

God Bless!

------------------
Sam Washburn

[This message has been edited by samw3 (edited July 16, 2007).]

That said I managed to find some (rather general but never the less useful) tips on MSDN:

http://msdn2.microsoft.com/en-us/library/ms973839.aspx

and another site:

http://community.bartdesmet.net/blogs/bart/archive/2007/02/27/c-quiz-need-for-speed.as px

[This message has been edited by Calin (edited July 16, 2007).]

I recommend a terrific book by Jeffrey Richter called CLR via C#. He takes you down to the actual Intermediate Language (IL) code to see what is truly happening. You can actually see, "Ohhh, this line of code will actually be three lines of IL code, but doing it this other way can do it in one."

I mentioned the book several times in the "Weekly Updates" thread. I stopped reading the book when I got caught up in learning OpenGL for work several months ago. I need to start reading it again.

http://www.gamedev.net/community/forums/topic.asp?topic_id=455825

------------------
Check my C# libraries

[This message has been edited by Calin (edited July 17, 2007).]

quote:

---

Originally posted by samw3:
"premature optimization is the root of all evil"

---

This quote is nearly meaningless when it comes to game development. All game code should be written with performance in mind. Every time you create a new structure or container or list, you should think about size, performance, etc. It's much easier to write an algorithm right the first time, than have to go back and rewrite it when performance becomes an issue. Of course, you have to have an feel for what kind of operations are more expensive that you have to watch out for. It also helps to know which algorithms are more efficient for large or small data sets. Shaving a random clock cycle here or there randomly isn't going to get you much.

------------------
+---------+
|steveth45|
+---------+

quote:

---

Originally posted by steveth45:
This quote is nearly meaningless when it comes to game development.

---

I've spent the past few years working to try and be a better programmer, and I've learned that in most of the software development world, human development cycles are worth more than processor cycles. It is with this in mind that I've tried to train myself -- valuing readability, maintainability and expandability over performance. Not that game developers don't value this, but it's a very different field. At my current job, the software that I'm working on is 15 years old, and it will probably be used (in some form) for at least that long into the future. While much game code is brought from project to project (from what I understand, ID does this with its game engines), cutting-edge game developers need to put an extra priority on optimization that I didn't quite understand before.

I think in the casual game market, optimization isn't quite as important. The important thing with a low-volume game is to keep your costs low, and that means it's more important to write code as-quickly-as-possible rather than write code that runs as-quickly-as-possible.

Still, performance is important -- and there are many little things that you can do to increase the overall performance without necessarily making your program more complex or hard to maintain. Simple things like understanding the rendering pipeline, how memory is allocated/passed, when to use hashes/lists/arrays, etc, are necessary when making any game. But then there comes this whole other level in professional game development that totally boggles me -- knowing how many cpu cycles each math function takes, and how to do certain operations in an esoteric-but-faster-way, managing memory more precisely, etc etc. It's a lot of crazy little things that add up, and it's really helped me understand that while I may be a decent programmer, I'm not nearly as good as I'd like to be.

So yeah, this just touches on something that I've been learning lately, so I thought I'd chime in.

--clint

[This message has been edited by HanClinto (edited July 17, 2007).]

quote:

---

premature optimization is the root of all evil

---

This is an oft misunderstood quote. This doesn't mean "good designs are evil" nor does it mean "speed of coding is more important than speed of program".

Optimization, by definition, is a refining process. In most cases this refers to program speed but sometimes also to size.

Premature optimization is refining a piece of code too much, before you know the performance impact it has on the program as a whole.

quote:

---

It's much easier to write an algorithm right the first time

---

If you have met the design specification in functionality and performance then the code is "right". Right? How can you tell the true performance without profiling the code? I would think that most people make a best guess about the algorithm to use based upon experience, implement it then profile it. Skip the ones that are sufficient and optimize the bottlenecks.

If you surpass the design spec, optimizing areas that don't need to be, you are wasting the company and client's money. I know that rubs some people the wrong way, but its true.

Some purist coders like to make statements like "if I wrote windows xp it would run on a 486 with 8MB of RAM". Well M$ could probably do that too if they threw enough money at it and rewrote the whole thing in hand-tweaked assembler.

These same coders like to nitpick about how tight they can get their loops, implementing pieces in asm or microcode. This is ludicrous if that part of the system does not need to be optimized. It is also the reason why so many software projects go way over budget or never get finished.

Well, enough ranting from me.

So, to keep thread on track, I misunderstood that Calin was looking for speed performance best-practices to hone his skills. His comment about "how long does it take a call a function" seemed to reveal a habit of premature optimization, and I was just trying to offer some wisdom--from one recovering tweak-a-holic to another.

The links were very informative. I wasn't aware that jagged arrays performed better than multidimensional ones--some more digging found this also applies to java and c++.

God Bless!

------------------
Sam Washburn

[This message has been edited by samw3 (edited July 17, 2007).]