Re: messing with branch prediction

From: Date: Tue, 20 Jun 2006 14:18:26 +0000
Subject: Re: messing with branch prediction
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-24161@lists.php.net to get a copy of this message
I think it's a nice idea but I doubt it's very useful at this point. It doesn't seem to significantly affect performance, which is inline with some tests that we have done in the past, where it's really the hardware management of branch prediction and cache size which affect this. I doubt that make such code changes will affect that in a significant way. We are playing around with some memory management issues, and are relying on some hardware branch predicition there (i.e. hoping that the hardware will play nice with if() statements that always evaluate the same). It seems that the hardware is playing pretty nice with us.
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; 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). Nuno

« previous php.internals (#24161) next »