Balancing Memory Usage vs Performance? 51
TwistedTR writes "I work for a company currently developing an application to run in an environment with a very small sum of available memory (sub 6 megs). My boss and I are in disagreement over speed vs memory overhead. He feels that speed is 100% key reguardless of the memory overhead required to meet it. The application is very math intensive so the more lookup tables we pre-generate at load time the faster the overall application runs. However, my boss is having me take us dangerously to the point where our target environment is going to run out of memory. The application makes use of user inputted data, and if the user so chooses it can be a WHOLE lot of data, which also uses a decent chunk of memory. My boss will not fold on my request to sacrifice some speed to prevent a possible fatal memory fill up. Has anyone out there had experience in dealing with developing in a simmilar situation, and if so do you have any ideas of how to balance performance vs memory on such a restrictive environment?"
Lookup tables don't have to be permanent. (Score:4, Insightful)
Easy.
Re:No-one needs more than 64k! (Score:2, Interesting)
You are lying.
Lunix [sourceforge.net] is designed to run on the Commodore 64, which has only 64k of RAM memory (and only about 30-40k free at that).
Posting as non-anonymous because I'm amazed that trolls keep using a misspelling of Linux as some kind of insult when its actually a totally different piece of software...
Re:No-one needs more than 64k! (Score:1)
Re:No-one needs more than 64k! (Score:2)
Re:No-one needs more than 64k! (Score:1)
Actually it was 640k, and he said it around 1981 (Score:1)
Re:Actually it was 640k, and he said it around 198 (Score:2)
OT: Tired of "my boss makes me do x" questions (Score:5, Insightful)
* The tone is almost always a bit whining
* The "facts" are presented by one of the parties only, and I bet they have been coloured by personal views most of the time
Interestingly enough, though, the high number of post about evil and/or stupid managers lead me to believe that the power distance between manager and knowledge workers might be a bit too large in the posters countries.
I'm a developer myself, and I find that my managers listen to me, and I can't recall a situation where I have explicitly been told to do something. I things were different I'd find another job - simple.
Re:OT: True cases (Score:2, Insightful)
In essence I can second that. Doing IT support of all kind (from desktop support to setting up large scale WANs) I know customers do those things:
The computer must run all the time, but when they see the price for a full clustered shared RAID system, they suddenly can accept a downtime of 1 day (complete hardware failure).
They want to keep backup data for at least one year, but at the price of those SDLT taped, they tend to choke and cut it down a lot.
Fully redundant links (downtime is not acceptable), but in the end they choose a simple T1 (with service agreement for 99.x% uptime guarantee).
The point of those examples? Customers have wishes without the full knowledge of the consequences. Like the boss who thinks "Speed is everything". While it now is very convinient to say "My boss said so, I know it will fail, but he will be blamed." this does not work. Customers (and bosses) have dreams and wished, but it's up to us (engineers, programmers) to pull them down to Earth and explain them why it's a bad idea and how to compromise, so everyone is happy. So far, this worked very well for me. I bet this works for most bosses too.
PS: I know there are some bosses/customers/etc. who absolutely know better, no matter what you do. And the answer to the problem is: use look up tables to gain speed if there is memory available, drop them if memory gets tight, and do a graceful abort if memory is full. And limit the valid input to useable amounts by definition (Specs).
Re:OT: Tired of "my boss makes me do x" questions (Score:1, Insightful)
So you're a technology prima donna with an ego the size of Jupiter, and an explosive temper to match. Sounds pretty standard for a software developer to me.
6 megs of memory, storage, cache or all of the... (Score:2)
What is the complete list of resources available and can you use them all?
Can you generate some dynamic tables at startup while keeping the most used ones in cache, loaded from storage? I don't mean cache as in a web browser cache, I mean processor cache as in fastest access.
Keeping the most used, hopefully static lookup tables in cpu cache is wonderful. Then generate the infrequently changed tables and store in RAM first then generate the dynamic user data tables from storage and swap in and out of RAM as needed or as memory use dictates, load balance by percentage with the application tables most used.
If you're working strictly with something like flash memory this will be much harder to do. No 'storage' just RAM and cache, or maybe just RAM/ROM... ugh... hardware.
More info please.
Do both (Score:2, Insightful)
Do some profiling on a simulation to figure out how much memory it takes to accomodate certain amount of user data.
Based on your profiles, generate only as many tables as you can comfortably fit. Obviously, fit the most important, speed improving, tables first.
Compromise by reducing dynamism (Score:5, Insightful)
You seem to have two main issues here. The first is that a person with (assumedly) less technical competance than you is dictating technical policy; and the second is that the usage of this application is too dynamic to allow for what your boss wants to do.
You need to establish how technically competant you are compared to your boss. Can you resort to hard technical fact to prove your case? Can you show that the speed sacrifice is negligable? If it is not, can you justify it?
The last point is important: if speed is so important (and you have to conceed that your boss is more driven by customer requirements than you are) then maybe you need to compromise on some other aspect.
It is already clear that, although customers can enter any amount of data, they can't enter 6Mb, because there are no enough resources. What about 4 Mb? 2Mb? How much is too much. Decide on a reasonable upper limit for customer data, and work from there. On a system with the limitations you have, this should have been part of the design spec.
Once you have determined an upper limit for customer data, you can calculate how much memory you have permanently available. It may be possible (depending on your app) to use additional memory when the customer supplies less data.
Oh come on (Score:3, Insightful)
Suck it up, and do your job like you're told. If he's wrong, you'll all find out the hard way. If he's right, I bet you'll never follow up with us.
Re:Oh come on (Score:2)
Reminds me (Score:2)
Just bear that in mind when someone says speed is everything. If you've got time, give them a lookup table and see if they really mean that.
Re:Reminds me (Score:1)
Yeah, lookup tables are cool. I recently wrote a Life implementation [primenet.com] for an old 890kHz CPU [primenet.com]. The CPU itself is approximately a 0.1 MIPS device (0.89 MHz, average instruction length around 8 or 9 cycles).
Even on that slow machine, I had Life running at a respectable clip. I used one lookup table to handle packed arithmetic (I did 8 parallel 2-bit adds in a single 16-bit accumulator), and another to handle the life/death state transitions. I used yet another lookup table to map life cells to pixels on the display (since the display has a funky encoding). In the end, I had a 32x24 life field running at about 8 frames per second on that beast. The entire code was about 1K words, and the RAM footprint was tiny too (about 240 bytes for the life state, 32 words for stack, and 240 words of display memory).
You do have to balance lookup tables against raw calculation though. Keep in mind also that lookup tables can lead to local speedups and global slowdowns. On modern machines, for example, lookup tables can thrash out your L1 caches (or in extreme cases, your L2 cache). Remember that optimization is a global problem.
For instance, if you're writing a Variable-Length Code decoder for something like MPEG video decode, you can't just make a lookup table for the maximum code length. Well, technically you could, but since the maximum code length is 26 bits, you'd be in for a 64 mega-entry table. If each table entry is only four bytes, that's 256 megabytes. So obviously, you have to make some engineering tradeoffs.
My personal rule of thumb is that lookup tables shouldn't be much larger than 4K entries, unless performance is absolutely critical. The tables should actually be smaller if at all possible.
--JoeBoss's problem (Score:3, Interesting)
--jquirke
Re:Boss's problem (Score:1)
Re:Boss's problem (Score:1)
Print out the email chain and then you are off the hook.
Re:Boss's problem (Score:1)
First if you drive the email conversation correctly you can make him basically order you to make the descision.
Then when push comes to shove you take it to him first when he tries to push the blame. If he won't correct the problem a paper copy goes to his boss and on up the chain and an electronic copy goes to everyone in the company with an explanation. So even if you loose you win.
Re:Boss's problem (Score:1)
If the guy really is F*cking you and you can prove it you can either take him to court for your job back( there is already way to much suing going on and you probably don't want to work there anyway ) or you can embarass him as publically as possible.
Not enough information (Score:2)
This sure sounds like a case where the only logical thing to do is to implement the code both ways if at all possible, and to benchmark both to determine whether the more compact version is fast enough for your needs.
Small amount of memory? (Score:2, Insightful)
6 megs is one hell of a lot of memory. What kind of bloatware world have I fallen asleep and woken up to find myself in?
Dealing with the Boss (Score:3, Interesting)
The design review came back with several comments abouts the scalability of the application, performance, stability etc. with buzzwords in appropiate places. Most of the comments very total BS. I tried to fight those arguments, but with little sucess. My boss had little understanding about how the whole thing would work, but sided with the reviewer because of his/her credentials. After several days of impasse I finally caved-in and changed the design document to match the reviewer's ideas. However, the finally code was based on my original design. No one knew. My boss was happy, the reviewer was happy and I was happy. 3 years later the customer needs have increased by 5 times the original planned system capacity, but it has performed flawlessly.
I am not suggesting you do the same. I was I playing a dangerous game - one that was necessary for the project's success.
Re:Dealing with the Boss (Score:2)
That's evil. I like it ;-)
Kudos.
Sounds like you haven't got your requirements down (Score:2)
You need to do that, and write it down between you. Then you need to get your manager to sign it off. Then when your manager says- "you need to make it faster" then you can point to the requirements and say- I've achieved 1 ms, like it says here.
Otherwise, you will never be finished and never deploy your system. It's nearly always possible to modify the code to improve performance.
I agree with the other posters too, if you have to throw away some part or all of the tables to do a user request, do that, and recalculate them afterwards.
Memory isn't always fast (Score:4, Informative)
The real issue becomes that LUTs aren't always fast. And bigger ones are slower because of the lower probability of a cache hit. DRAM has horrible latency, 120-180ns that corresponds to 120-360 CPU clocks. You can do alot of calcs in that time! Also the LUT can flood out cache to incur more cache misses.
I hope you are not right about big user data being fatal. It should never be. The pgm might get into swapping or thrashing and run real slow, but crashing is not acceptable. And how does your pgm perform when swapping? It will always be slower, but some go into light swapping while other pgms get into heavy thrashing.
Re:Memory isn't always fast (Score:1)
Umm.... keep in mind that not everything runs on a PC with a hard disk. Sometimes swapping isn't an option-- there's just no where to swap to.
The issue with the question is that it basically states that the user has no upper bounds on how much memory they can manually enter. What should happen is that either (1) when memory fills up, the user cannot enter more; or (2) when memory gets low, deallocate LUTs and shift to real time calculations at the expense of speed (and if memory still fills up, see #1)
Also, it may not be possible to add RAM to the system. I've worked on systems where I only had the 512 BYTES of RAM, plus a 2K ROM. Adding more RAM would have doubled, tripled, or more the cost of the end system which wasn't an option.
rob.
oh no. (Score:1)
What about a .db file? (Score:1)
It would make your memory overhead problem go away, though it brings up the new issue of disk space....
Your boss is just following Bill's law... (Score:2, Funny)
- Bill Gates, 1981
Solution to both problems ... (Score:2)
Just in time lookups (Score:2)
begin
mysinfunc=sinfunc;
dostuff
end
function sinfunc(x)
if(loadsofmemory){
build(sinlookuptable);
mysinfunc = sinlookupfunc;
}
return sin(x);
end function
//you memory manager can do somthing like this
function allocatememory
if(memory_low){
mysinfunc=sinfunc;
drop(sinlookuptable);
}
end function
The lookup tables should be stated, so the one that gives the least performance increase is droped first.