Slashdot Mirror
Balancing Memory Usage vs Performance?
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?"
You want to make the lookup tables dynamic in the sense that you may deallocate them when you run out of memory. At the expense of a conditional statement, you have fast lookups... until you run out of memory and at this point you explicitly calculate everything.
Easy.
environment with a very small sum of available memory (sub 6 megs)
Didn't Bill already explain to us that no-one ever needs more than 64k? So, what's your problem?
You're not seriously saying thta Bill could be wrong, are you?
I'm tired of these questions.
* 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.
6 megs of memory, storage, cache or all of the above?
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.
A fool throws a stone into a well and a thousand sages can not remove it.
Prioritize the tables that you need to generate.
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.
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.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
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.
of a programming assignment (in z80 assembly) I was given -- basically a bit of number crunching. It was to be marked purely on execution speed, with the lecturer betting a considerable (to a student anyway) sum that no-one could beat his code. He was rather upset when I wrote something two orders of magnitude faster. I'd precalculated all the results and stuck them in a lookup table. I even aligned the lookup table in memory, so the entire thing was three ld operations.
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.
Well if the project flops because there isn't enough memory, then it will be the boss who takes the blame, not you, so I suggest just go along and agree with him, then laugh at him at the end when the code has to be rewritten and say "I told you so".
--jquirke
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.
Says the RIAA: When you EQ, you're stealing bass!
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).
6 megs might be seen as some to be a small amount of memory. Please don't use up the adverb 'very' in this fashion, however. Many of us have coded in less than 100K of memory. Some of the smaller controllers (i.e. Motorola 6805s) have less than 128 bytes of Read/Write memory (and less than 2K of program memory) and are quite useful. Assembly language becomes necessary.
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?
Three years back I was the development lead of a certain project. The project design was to be reviewed by a person from some other group. The reviewer in my opinion was a excellent speaker but nothing more than. Because of the reviewer's expierece he/she carried a lot of weight in the organization. The project had several complexities which utimately meant that other than me, the reviewer was the only person with the right 'qualifications' to understand the system. The UI design had already met customer approval, so only the behind the scenes stuff was under review.
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.
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.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"reguardless
Send my "reguards" to your grade school English teachers...
This poster's name secretly replaced with Folgers Crystal Meth
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.
Your life is gonna suck, and then when the project fails and they downsize ya, well I hope ya have savings.
A comprimise solution might be to store the lookup tables on disk in something like a Berkley .db file? While it would be substantially slower to retrieve data from the disk than directly from RAM, it could still be faster than doing your cpu intensive calculations.
It would make your memory overhead problem go away, though it brings up the new issue of disk space....
SpyDock: Scientific Python in a Docker container
640Kb ought to be enough for anybody
- Bill Gates, 1981
From excellent karma to terible karma with a single +5 funny post...
ok, instead of insisting your boss is lame and you are right, how about compromising -- write two vesions of the code -- one that uses lookups (which you generate at runtime), and one that uses no lookups but saves ram. Switch between the two as necessary :)
Religion is a gateway psychosis. -- Dave Foley
Why not make the system drop lookup tables if memory is getting low and rebuild them when there's enough memory free. e.g.
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.
thank God the internet isn't a human right.
"Nobody will ever need more than 640k RAM!" -- Bill Gates, 1981 Altavista : "Nobody will ever need more than 640k"
Glonoinha the MebiByte Slayer
Well now that I've tried Altavista I appreciate Google even more, but all Altavista seems to return is other people saying that Gates said that. I can say that the missing 18.5 minutes of tape was Nixon saying that Coca-Cola is a miracle drug and Pepsi-Cola (for whom he worked at one point) is made from fetuses conceived and aborted expressly for that purpose, but no matter how many times it might get repeated, that won't make it true (or false, for that matter).
I see even classic Slashdot is now pretty much unusable on dial up anymore.