4 and 5 are often underestimated, while critical.
-
-
-
I'd personally suggest they belong at #1 and #2 spots. You cannot 'design for performance' without a knowledge of the hardware nor the data.
-
It's not a sorted list. :) It's in the order they popped out of my head.
কথা-বার্তা শেষ
নতুন কথা-বার্তা -
-
-
sorry, have to side with codewisdom here; then again, i haven't shipped as much ;)
-
it's been my experience that our engine coders have been overly paranoid about optimization issues and it was usually always the case that we could fix any issue we had in the last weeks before certification.
-
you're a lucky man then and your code base was probably way above average to start with. the problem with the received wisdom is that it gives inexperienced people carte blanche to do really terrible things...
-
yeah but how unrewritable is it really when you otherwise obey KISS?
-
inexperienced people tend to underestimate how simple simple should be
-
ah, i see the solution is then not to be inexperienced!
-
indeed! practice makes less awful
-
Also ... problems have an inherent level of complexity that is required to solve them even with oracularly clean code. As the problems get bigger, that complexity gets higher, thus the cost of basic restructurings.
কথা-বার্তা শেষ
নতুন কথা-বার্তা -
-
-
1. Don't do it. 2. Don't do it yet. 3. At this point it's too late to rewrite half of the codebase to fix performance, so blame artists and demand that they cut and optimize content.
-
I really wish this would sound like a joke but after few years in gamedev it hits too close to home... :(
কথা-বার্তা শেষ
নতুন কথা-বার্তা -
-
-
Oh dear, you went wrong at (1). Only design for performance **if definitely needed**. Otherwise don't. For many scenarios its way way cheaper to buy better hardware than waste time on performance improvements.
-
Well the hardware isn't getting "better" very quickly these days - if we're talking CPU.
-
Caveat: I’m biased here ;) Depends on definition of “better”: what timeframe, which vector (cost, clock, IPC, number of cores, TDP, etc), which algorithm To paraphrase: I’ve seen code which you people wouldn’t believe. Profilers on fire due to C++ intellectualism,... Time to die
কথা-বার্তা শেষ
নতুন কথা-বার্তা -
-
-
While there's some truth to "premature optimisation is the root of all evil", you sure as hell aren't going to feasibly rearchitect software to use (for example) data-oriented design techniques two months before ship. Performance has to be considered in tech design from the start
ধন্যবাদ। আপনার সময়রেখাকে আরো ভালো করে তুলতে টুইটার এটিকে ব্যবহার করবে। পূর্বাবস্থায়পূর্বাবস্থায়
-
-
-
I would want to add to point 7: Verify your assumptions both before you start a big optimization refactoring, and verify your assumptions before it has been done. Good understanding of profiling tools is crucial for this.
ধন্যবাদ। আপনার সময়রেখাকে আরো ভালো করে তুলতে টুইটার এটিকে ব্যবহার করবে। পূর্বাবস্থায়পূর্বাবস্থায়
-
-
-
Rules of optimizations must come after rules of good software engineering. True, it's possible to optimize terrible code, but eventually spaghetti code would lead to performance issues anyway.
-
Too often the opposite comes true : people says "root of all evil..." without understanding it, over engineer and leed to spaghetti c guide that cannot be optimized without rewriting it from scratch. Not understanding how to map data with hardware ram/L2/L1 is the root of evil.
-
OK, nvm knowing how to write proper code and let's focus on optimization only, do you prefer to work with people that know how the hardware works instead to work with people that know how to optimize algorithms and when to use the right data structure to reduce their complexity?
-
Wrong : proper code is not incompatible with optimization. Actually, bad data structure/architecture thus memory layout is the worse thing one can do in both dimensions. Good code is clear AND fast. If you don't have both, well... Sorry, that's bad code.
-
it's very confusing, but OK
-
Why confusing? Simplifying, there's 2 types of optimizations: local (sse, prefetch etc. 2x to 10x faster code; can be made later) and architectural (up to 400x faster with better use of L2). Archi has to be made early enough, or it becomes very difficult&costly to implement
-
In my experience, SIMD-ifying / vectorizing isolated functions often results in a 15x speedup, not 10x. I've achieved this result multiple times in my career (both previous + next gen and PC) so I consider it a good goalpost.
-
Those numbers were more order of magnitude rather than exact measurements ;)
কথা-বার্তা শেষ
নতুন কথা-বার্তা -
লোড হতে বেশ কিছুক্ষণ সময় নিচ্ছে।
টুইটার তার ক্ষমতার বাইরে চলে গেছে বা কোনো সাময়িক সমস্যার সম্মুখীন হয়েছে আবার চেষ্টা করুন বা আরও তথ্যের জন্য টুইটারের স্থিতি দেখুন।