Messages in this thread | | | Date | Thu, 11 Sep 2003 19:39:54 +0200 | From | Andi Kleen <> | Subject | Re: [PATCH] 2.6 workaround for Athlon/Opteron prefetch errata |
| |
On Thu, 11 Sep 2003 18:32:45 +0100 Jamie Lokier <jamie@shareable.org> wrote:
> Andi Kleen wrote: > > > if ((addr & 3) == 0) > > > return 0; > > > > Maybe. But gcc generates quite good code (binary decision tree) code for > > the switch() statement already so I don't think it is worth it to go > > through complications just to avoid that. > > > > The decoder looks big in C, but when you take a look at its hot path in > > assembly it is quite fast. > > I wonder. No part of the signal path looks especially slow, and yet > as a whole it isn't that fast. The odd percentage slowdown here and > there is quite bothersome. > > GCC generates a decision tree. You realise that about half of the > branches in that tree will be mispredicted?
True. Doing a BTSL in a bitmap would be probably faster to check bytes in a switch. Or maybe gcc should do that, but it doesn't.
But I doubt the small performance advantage of that for an still quite obscure path is worth the code uglification that would be require to do it without gcc support.
To put it into perspective:
signal exception path is thousands of cycles, we're talking about tens of cycles here.
-Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |