 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / CodeWarrior / September 2005Turning off the optimizer
I've got some hideous code that I have to compile, which has functions so big that the optimizer barfs on them. Changing the code isn't an option - believe me, I've tried! In the past I've used #pragma global_optimizer or #pragma optimization_level to control the optimizer's behaviour for this file only, but it doesn't seem to be working - as of Pro 9.6 (and perhaps earlier). If I turn the optimization level down in the project settings it works ok - but that's obviously not ideal as it affects other files too. If I leave the optimization level on 4 in the project, but use #pragma global_optimizer off in the file, I still get an error: Error : PPC Optimizer computes it would need more than 128M of memory to compute register def-use chains. Key Optimizations Failed Limit currently set to 100M Increase limit using '#pragma ppc_opt_defuse_mem_limit 128' Is this a known bug? Is there a way to turn this optimization off, since it seems to be on even when global optimizations are turned off? >I've got some hideous code that I have to compile, which has functions >so big that the optimizer barfs on them. Changing the code isn't an [quoted text clipped - 16 lines] > Limit currently set to 100M > Increase limit using '#pragma ppc_opt_defuse_mem_limit 128' Did you do what it said to do? >Is this a known bug? Is there a way to turn this optimization off, >since it seems to be on even when global optimizations are turned off? Where are you setting the pragmas, you don't want to use the Global one. Of course you could always compile the big functions as a lib and add them and avoid a lot of problems. Ron  SignatureCodeWarrior Community Forum is a free online resource for developers to discuss CodeWarrior topics with other users and our staff -- http://www.codewarrior.com/community -- Ron Liechty - ron.liechty@freescale.com - http://www.codewarrior.com Yeah - I have experimented with #pragma ppc_opt_defuse_mem_limit. I am using the pragmas in the source file itself, after all headers have been included. One of the main issues is simply the amount of time CW will spend on this file. The code is utter rubbish - 9000 lines for one function (!!), but there's nothing I can do about that as it's not my code. I tried splitting the most problematic functions into their own files, but if anything this made things worse (Codewarrior now reported that it would need an 850Mb defuse mem limit to optimise this function!). Basically, it would be good if I could just tell it not to bother trying this optimisation for this function! Is there a way to turn just that optimization off with a pragma? > Yeah - I have experimented with #pragma ppc_opt_defuse_mem_limit. I am > using the pragmas in the source file itself, after all headers have [quoted text clipped - 12 lines] > trying this optimisation for this function! Is there a way to turn just > that optimization off with a pragma? 850MB should not break the bank. Each process on the Mac has 4GB of virtual address space at its disposal, free disk space permitting. Certainly, the compilation will be slow and use a lot of disk space. But compiled as a static library, this function only has to be compiled once. After you have it compiled as a static library, just add it to the project it is currently in and forget about it. And look at it this way: the one time upfront time and memory cost needed to compile the optimized function could produce a much faster executing function in the app. So the one-time compile-time cost could pay for itself many times over, if you were to take into account the time saved each and every time that the optimized function executes when the app is run. Greg On some machines that this is being built on, 850Mb is considerably more memory than the machine has (again, a factor outside of my control). The code is already compiled in a library, but it depends on stuff that changes often, hence a full rebuild is often required. Building on a Dual processor G5 takes more than an hour, with an appreciable amount of time spent compiling these long functions. This is problematic when the PC guys can use Incredibuild to build in parallel, but I am stuck with one processor of one machine. Normally I wouldn't be doing final builds so often, but we are close to crunch time and I'm doing performance profiling and optimisation, so ironically I have to keep recompiling code in this very area. Having to wait an hour each time you make a change isn't a great aid to productivity! I will try turning the limit off, just out of curiosity to see how long it takes to build :) It would be useful to know how to turn that optimisation off though. > On some machines that this is being built on, 850Mb is considerably > more memory than the machine has (again, a factor outside of my > control). Every Mac has 4GB of memory at its disposal. At any one time some portion of these 4GBs of memory in use will reside in RAM and some will have been swapped out to disk. The amount of RAM installed on a machine changes the the RAM-to-disk ratio but has no effect on the 4GB limit. The amount of free disk space can affect this limit, since if there is no disk space free, additional memory cannot be allocated. Greg > Every Mac has 4GB of memory at its disposal. That was true in 32-bit world. Mac OS X now supports 64 bit addressing, so the theoretical limit is actually 16 exabytes, which is a unit so big you'll have to look it up in a reference book :-) Ben SignatureIf this message helped you, consider buying an item from my wish list: <http://artins.org/ben/wishlist> I changed my name: <http://periodic-kingdom.org/People/NameChange.php> Yes, thank you very much for that lesson, I know how virtual memory works. Can anyone tell me if there is an option to turn that optimisation off? > I've got some hideous code that I have to compile, which has functions > so big that the optimizer barfs on them. Changing the code isn't an [quoted text clipped - 19 lines] > Is this a known bug? Is there a way to turn this optimization off, > since it seems to be on even when global optimizations are turned off? Why not go for broke and use: #pragma ppc_opt_defuse_mem_limit off to disable the optimizer's memory limit? After all, this code may have the most to gain from being optimized. Greg |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.