Archived

This topic is now archived and is closed to further replies.

walkingcarcass

complacency

Recommended Posts

a little history... in the early days of games, every cycle was squeezed out of the CPU. of course, we didn''t have to share resources then. when multitasking operating systems came out, things got a little inefficient, but processors had sped up so the overheads were relatively small. As the state of technology improves, so does the complexity (windows has peversly got exponentially more complex, but arguably passed it''s peak) drivers and APIs standardise this so the code volume overhead per program is smaller of course there''s an extra layer of third-party code slowing things down, but computers had sped up so the net amount of resources to our engines still increased with time now the hardware is approaching a physical limit. frequency obstacles (heat etc) spawned "intelligent" instruction execution long ago, but soon we will have to accept that chips aren''t going to get much faster without drastic changes in technology (a circuit track can only be made so many atoms thin) in the medium term, multiprocessor systems will become more common for those after the extra speed. but this will mean paying for 2 processors over the years we have allowed ourselves a little slack, and the wasted resources have grown. why the hell is there no standard direct-disk-access API? why is several percent of 256Mb RAM unavailable as soon as I boot? and whose dumb idea was it to implement a "high speed" games API with COM? why do we have to share CPU cycles with a kernel which by all rights should be idle until a hardware interrupt stimulates a message? why do compilers build a stack frame by default instead of passing arguments in registers, and popping arguments as needed to increase the number of instructions in the pipeline? Why the hell do we put up with code bloat? why oh why do we argue about wether assembly is still useful when you can spend 10 minutes hand-coding a 300% faster blit? when the pressure re-builds to remove the bottlenecks, will we go at it with the ruthless cycle-sucking in the "Golden Era" (cough) or will we be too entrenched in the glory of polymorphism, VFLTs (spit) and resource sacrafice in the name of "fairness"? should we once-and-for-all standardise the driver interfaces so programs can have honest-to-goodness direct access to hardware in the same way DirectX does? should someone write a games OS that supports every important Win32 API function and runs normal windows programs but boots in several seconds and allows an application to hog the system? in the meantime, to scrape up a few extra cycles, i''ll just bump all my processes'' threads up to the highest priority... ******** A Problem Worthy of Attack Proves It''s Worth by Fighting Back

Share this post


Link to post
Share on other sites
Because development schedules doesn''t increase at the same rate as the complexity of the product. Which means something had to go, and as optimization is typically the last step, its usually the first to get cut.

Software is a business and companies need to make money to stay in business. A project will have a deadline based on the competion''s estimated release date or expected sales. Most game sales cant support more than about 2 years of development. And there is only so much you can do in that amount of time.

Share this post


Link to post
Share on other sites
Yeah, the Windows OS has some room for improvement, but things arn''t as bad as you make them sound.

quote:
Original post by walkingcarcass
Should someone write a games OS that supports every important Win32 API function and runs normal windows programs but boots in several seconds and allows an application to hog the system?



Try this yourself; you''ll find the answer to every question you asked.

Share this post


Link to post
Share on other sites
quote:
Original post by pawn69
Because development schedules doesn''t increase at the same rate as the complexity of the product. Which means something had to go, and as optimization is typically the last step, its usually the first to get cut.

Software is a business and companies need to make money to stay in business. A project will have a deadline based on the competion''s estimated release date or expected sales. Most game sales cant support more than about 2 years of development. And there is only so much you can do in that amount of time.



Absolutely spot on. I agree 100% with pawn69 on this.

Games programmers aren''t being complacent - it annoys me that on every product I work on I get a week to optimise, if that. I''d personally love to work on a project where all structures were cache optimal, access patterns best for virtual memory, even for RAM interleave.

Also the OS and hardware vendors often force us to approach things in a high level way.

For example if I were to write GameCube code which hit the hardware for every last % of performance, the game would very likely fail Nintendo lot check.


As for some of the other points in walkingcarcass''s post:

"high speed games API with COM" - if you''re talking about DirectX, it''s all about call frequency - all of that API is designed for a low call frequency - a game using the API well could get away with as few as 50 DirectX calls! (a game I worked on did!!). So essentially 50 calls via a vtable. There are MUCH bigger bottlenecks - virtual memory?, PCI bus contention?, AGP bandwidth?...

"standard direct-disk-access API" - unlike single manufacturer systems (Amiga, Mac etc), the PC is a million manufacturers making stuff that can be connected in a billion different combinations. The result is the API can only reliably abstract at a high level to be able to cope with the nuances of each device. Furthermore far too many programmers don''t know what they''re doing when it comes to low level hardware access - they get things wrong - end users suffer. [Remembers the Amiga days: knackered track step motors on old A500s before CBM put the hardware track0 lock in due to so many coders getting that find track 0 code wrong, same with the 3ms step pause. Other people not checking the media type info when issuing those DoIO() calls - result antivirus bootblocks intended for floppy use ending up on IDE drives etc]

"why do compilers build a stack frame by default instead of passing arguments in registers," - Try compiling code on an Amiga or a Mac - not much you can do when to keep code compatible you can only rely on 4 proper registers. More people bought PCs than other platforms - the worst technology succeeded - don''t blame the programmers

"why oh why do we argue about wether assembly is still useful when you can spend 10 minutes hand-coding a 300% faster blit?" - optimisation at the other end makes much more sense - 10 minutes of _design_ and _thought_ spent at the OTHER end usually results in much bigger perf. boosts - like 3000%... (e.g. concatenating blits, not clearing, changing flip order etc)



Even at home, although I occasionally go into a super optimisation mood (I used to do things like demos in 1K Amiga bootable bootblocks), I don''t have time to spend doing it - there''s far too many higher level problems to solve rather than spending time at the metal making small steps.

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

Share this post


Link to post
Share on other sites
quote:
Original post by pawn69
Furthermore far too many programmers don't know what they're doing when it comes to low level hardware access - they get things wrong - end users suffer....


Just because some programmers are too ignorant to get it right doesn't mean someone who can be bothered to do a little research and testing has to be disqualified from speeding up disk access


quote:
Original post by pawn69
10 minutes of _design_ and _thought_ spent at the OTHER end usually results in much bigger perf. boosts - like 3000%...


but if the basic blit code can be made 300% faster in 10 minutes of coding, that 3000% high level increase becomes 300% faster still!

********


A Problem Worthy of Attack
Proves It's Worth by Fighting Back

[edited by - walkingcarcass on January 19, 2003 6:08:38 AM]

Share this post


Link to post
Share on other sites