1 / 23

Program Reduction Focusing on Compaction

Program Reduction Focusing on Compaction. Benjamin J. Fruchter MS CS Candidate March 12 2004. Program Reduction. Any method or combination of methods that modify code to allow a program to be stored and run with less resources. Program Reduction Overview.

urbano
Download Presentation

Program Reduction Focusing on Compaction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Program ReductionFocusing on Compaction Benjamin J. Fruchter MS CS Candidate March 12 2004

  2. Program Reduction • Any method or combination of methods that modify code to allow a program to be stored and run with less resources

  3. Program Reduction Overview • Consumer driven push for smaller, faster, more powerful electronic devices • Same functionality, fewer resources, more constraints • Hardware advancing, but not enough to keep up with demand • Need a way to fit full sized programs onto much smaller platforms

  4. Constraints • Three major constraints • Space • Storage (ROM) • Runtime (RAM) • Time • Input reaction • General runtime • Energy • Batteries getting better but not fast enough

  5. Reduce, Reuse, Recycle • Various methods of reduction • Reduce functionality • Compress the code • Compact the code

  6. Reduce Functionality +/- • Quick • Takes very little time • Decide what is not needed and throw it out • No new development needed • Dirty • Loss of functionality only occasionally acceptable • Wasteful: getting rid of functionality that took time to develop and test

  7. Code Compression • Compressed code takes up less space without losing functionality • Similar to data compression • Uses smaller symbols to represent string of input • Use of language and grammar structure to create interpretable compressed program • Stored on ROM then decompressed at run time to avoid negating storage benefits • Many different techniques available some including hardware modifications

  8. Code Compression +\- • Effective storage space saving • Thorough algorithms combined with advanced hardware make effective solutions • Though space required is decreased often time and energy consumption increase • Work to decompress the stored code at run time requires costly computations resulting in decreased time and energy efficiency • Storage space decreased but often RAM space requirements increase

  9. Code Compaction • Irreversible modification to program code that reduces code size without losing functionality • Combination of various methodologies • Traditional compiler optimizations • Removing unused / useless code • Removing debugging information • Undoing programming standards set in place to increase readability or ease versioning

  10. Code Compaction +/- • More resource efficient in runtime memory, time and energy consumption • No functionality loss • Time performance often increases instead of decreased • Not as effective at saving storage space as compression • Many cases where certain methods can not be used

  11. Code Compaction • Warranted by object-oriented programming standards • Reduction of logical organization and readability to gain space • Consider: Java Applet Hello World • How many hundreds of lines of code are included? • How many of those included classes, methods, and fields are actually used?

  12. Application Extractors • Java Application Extractor (JAX) • Developed at IBM for use with J2ME • Very effective method of pulling out the functional pieces of a Java program • On average resulting in 40% smaller JAR executable • Particularly effective when a program includes libraries developed by third parties

  13. Jax • Process • Determine all entry points (by class) • Find all reachable / referenced classes • Create call graph to find unreachable methods • Jax allows you to choose which algorithm to use to construct the call graph (RTA, XTA most common) • Removes redundant fields • Unreachable or write only • Class hierarchy transformation • Name compression

  14. Jax – Unreachable / Useless • Classes • Not directly or indirectly referenced by the ‘entry point’ class or classes • Not a super class of a referenced class • Methods • Discovered via a call graph • Fields • Contained by unreferenced methods • Only written to, hence value does not effect outcome of program, so useless

  15. Jax – Call Graphs • Basic Theory • Play it safe and don’t remove unless sure • More complex than name resolution due to polymorphism • RTA – Rapid Type Analysis • Most common due to high speed and acceptable accuracy • XTA – Exact Type Analysis • More stringent but rarely worth the time decrease from RTA

  16. Jax • Class Hierarchy Transformations • Combining of adjacent (sibling) classes • When run time object size not increased • When program behavior not affected • Reduces number of class files each of which contain their own pool of literals and constants • Name Compression • All references in Java made through string literals • Reducing name length of classes, methods, fields all beneficial • Sacrifice readability for the space saving benefit

  17. Jax – Benchmark • Compaction of Hyper/J with Jax • Breakdown of space conservation Percent of Original Step Size Remaining Unreferenced classes 86% Redundant attributes 67.1% Unreachable methods 47.6% Dead fields 42.6% Class hierarchy compaction 35.2% Name compression 27.8% Run under 4 minutes on a 800MHz Intel based machine with 512MB of memory

  18. RISC Code Compaction • ARM Infrastructure • Two instruction sets available • ARM – 32 bit • Thumb – 16 bit • ARM – fast but takes up a lot of memory • Thumb – space efficient but slow • As always we want the best of both worlds

  19. Mixed Width Instruction Sets • Processor able to handle both sets of instructions • Able to switch back and forth between the two during program execution • Each set performs better under different circumstances • Those conditions can be programmatically identified using a heuristic to make the decision of whether to switch or not

  20. Mixed Width Instruction Sets • Switching done at a procedure level • All ARM code is first converted to Thumb code • The Thumb code is chosen if either • The instruction count is lower than the ARM code • The instruction count is higher by a factor of T1% but the overall size of the code is smaller by a factor of T2% • On average mixed code is nearly as small as Thumb code and runs nearly as fast as ARM • Stressing of low instruction count saves energy

  21. Mixed Width Instruction Sets • Switching between instruction sets more often would negate benefits due to high overhead • Other solutions include • Instruction coalescing (AXThumb) • Application specific code compression (ThumbScrews)

  22. Code Reduction • Many methods available • Few clear ‘best’ choices • Trade offs are usually involved • Classic space for time outside of compaction • Compaction options most attractive due to lack of performance hits

  23. Questions

More Related