Comments bellow: >-----Original Message----- > >First, let me thank you all that reviewed the patch. >When I first sent the patch to the list I didn't meant I >wanted it to be integrated with the main php sources. At least >before running some benchmarks and double-checking it. That >patch was just a quick&dirty write of my initial idea. Its >also interesting because I was thinking in extending the patch >to the memory management part, too. > >About the gcc heuristics on branch prediction.. Well they seem >to be somewhat good, but they are just heuristics. Surely gcc >can decide about >this: >ptr = malloc(3); >if (!ptr) return NULL;
Yep and CPUs are good at exactly this repetitive case. We checked this also when we did some MM changes. >that's pretty obvious that branch isn't likely to execute.. >But others might not be so obvious. The Linux kernel and the >GNU libc (where performance is really important) have been >using similar macros to mark the branch probability. > >When I finish my exams, I'll spend some more time tweaking and >benchmarking the patch on several computers with different gcc >versions and different cpus architectures (my Centrino isn't >surely a good place to benchmark server applications..) > >Other thing that may raise some concerns is the recent >addition of reflection data to internal functions. While it is >nice to have it, it may cause too much cache trashing. While >previously there was about 10 global ARG_INFO vars, now they >have exploded to 1 per function. It may have some impact on >performance. But I can't talk too much here, because I don't >know if that data is used only in compile time or in run-time >(on each function call or similar). This would be very interesting to find out. It'd be great if you could check it out. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
