>> I doubt anyone does I1/D1/L2 cache profiling for PHP. > > I did a little bit of CPU cache profiling of PHP using oprofile, more > out of curiosity than anything. It was a couple of years ago now. > > http://wikitech.wikimedia.org/view/Oprofile > > But you don't need oprofile, you can make changes based on theory, and > then measure the execution time of the result.
I don't know where to go with that. I so much agree. Yet it so much depends on what the theory is based on. But measurement and a decent test matrix is key. valgrind/callgrind and the others can help. Honestly, I think people should stay out of coding languages (either interpreters or compilers, where interpreters are the more complex case often best made easier by doing JIT) unless they have done CPU design. It is not like the pre-386 days. These days CPUs are designed for the compilers (either where they are, or likely where they will be). The CPU designer decides how the compiler should operate. It is their theories that matter. Not always -- just like in literature -- the author may create something that is beyond their own grasp and best understood by others. >> PHP doesn't ship with an optimizer, byte code cache, or JIT. > > But community members are developing those things nonetheless. > eAccelerator has an optimizer, there are several so-called byte code > caches, and Roadsend is a promising compiler project. Have been developing for a more than a decade... PHP4 was the last time there was real performance improvements in PHP itself. The fact that there are "several so-called byte code caches" does not equal a good thing. It means that PHP is broken and lots of people are trying to fix it. It also means that none have succeeded, as that would mean that one of them would be included in the PHP core by now. >> Rasmus had the idea that it should >> do simple things and be easy, and if you were going to do anything >> else, then you should have the money to do so. Fair enough really. > > Rasmus is not the whole community. Like a founder of a company that sets the corporate culture, don't count Rasmus out so easily. Founders earn such power. Until they are booted. It is not going to, nor should it, happen here. The guys at Zend muscled in to change the culture as well, and have succeeded to a large degree, pushing PHP into the enterprise by offering a "full" version of PHP, not free of course. And thus the reason for not having a byte code cache in the core. And the whole "optimizer" which was their decoder part of their encoder project was just making bad karma. Enough time has passed for a new round to wrestle control. We'll see how the FBJIT goes. Which just goes to show, if you really want something done, put some muscle into, take over or fork. Or keep to yourself. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
