Thread: Basic Programming model....

Do you think it is worth the effort to write code that is efficient in cpu cycles and small in ram footprint?

Or do you think that relying on the hardware to make up for bad code is the better idea?

An excellent example of relying on the hardware is windows itself, every new version requires a hardware upgrade to run properly.

Personally, I say that the software company that insists on forcing a hardware upgrade to use the new version of their software should have to purchase the new hardware for their clients.

In general I agree with GanglyLamb, however the other side of the coin is worth a look. I could not count the number of days I have wasted obsessing over tiny fragments of code which I eventually threw out or re-wrote anyways. You have to know where to draw the line. I hate to admit that theres ever a time when something shouldn't be done "perfectly", but there is, and I admit it. It all comes down to the matter of diminishing returns.

When you write an application i think you should consider both sides.

You want efficient code that will run fast, but you dont want to spend decades writting it. You have to decide where your application falls, it'll have to be balanced. Write the most efficient code for the time frame you have.

Sure if the application is small you can pass by with slow code you slapped together in a few hours. But for large applications you need to optimize the slowest parts (mainly long and intensive algorithms and memory management).

citizen,

okay, the game need better hardware, you go buy a better video card or more ram and it runs.

what about Windows Vista? you need to buy a new motherboard, cpu, ram hard drive, video card to use it.

Vista's features require a 3 GHZ 64 BIT cpu, and 1 gb ddr ram to function properly. if you don't have that then you will have XP with a couple more tools in it for your version of Vista.

and before anyone makes a comment about Longhorn, Longhorn was the development code name for Vista

Well you could make 4MB up of 2048 arrays of 2kB ... if optimization by your compiler or whatever is not done ... then there's a good chance all these arrays would end up in different pages ... creating more internal fragmentation. + Depending on which algorithme is used to determine which pages should be removed it could even be that there would be alot more page faults. Since you will be probably working on that 4MB array at approx. the same time , most of the pages that make up this 4Mb will either be just used, or yet to be used.

Now suppose you have a counter that keeps track of how many time a page is being used. Then use a timer to decrement the counter as time goes by. Then use a LFU algorithme.
With this example you are likely to get more pagefaults since there are more pages. As time goes by, the counters will decrease, making it more likely to be removed... while it actually shouldnt be removed since it's still a very active page.

It's not the algorithme that is bad in this case, its the design of the program. Since you have more pages, you need more lookups, which causes more time to pass before all pages we use in the 4MB are handled... which could eventually leads to a kind of Trashing effect ( although that depends on how many processes are in memory at that time and how much of the memory is being used ).

Of course in an os there are implementations to deal with this trashing...

Anyhow this is all very theoretical, in practice this is almost impossible to do, since for every other OS / architecture you would need to restructure your entire code ( which you don't really expect when working with very high level languages , you expect the compiler do this for you....)

Like i said its how your compiler handles these things.

And like lightatdawn said there's a limit for everything.

Originally Posted by Jaqui

Personally, I say that the software company that insists on forcing a hardware upgrade to use the new version of their software should have to purchase the new hardware for their clients.

If there was a way to program in which you got a perfect speed to size ratio and you didn't have to do things like sacrifice anything to get the best of everything, everybody would program that way. Considering that that approch hasn't come around yet in practical and modern software development, it kind of tells you something, huh.