On Sat, Jul 08, 2017 at 08:13:15AM -0700, Christopher Li wrote: > On Fri, Jul 7, 2017 at 6:39 AM, Luc Van Oostenryck > <luc.vanoostenryck@xxxxxxxxx> wrote: > > Here is some patches reworking the whole ptrlist API > > which move all the logic currently present in the macros > > in a small set of primitive functions using an iterator > > structure. > > I am not considering it for this release for sure. It was, of course, not meant for. > Actually, NACK on the function based iterator API. > > There is no much of a real function enhancement. > And it is a big slow down. See below. > I actually like Linus' macro based implementation. I want > to keep it that way. No problem. > It looks very clean on the caller side. It perform extremely > fast. All the internal variable will easy promote to register. But since all real use of the macros will call some functions inside the loops all those nice registers will need to be pushed on the stack. > I am all about using code to squeezing very last bit of performance > out of the hardware. Sure. Of course, I prefer for now to focus on correctness and robustness instead of hypothetical micro-performance. Hence all the fixes, the changes in the testsuite and all the other testing I made. And don't take me wrong, I've done my share of timing and profiling, as I'm *very* performance conscious. > Now the function based iterator: > ... > > Here is the program just iterate over a long list for many times > with some condition testing inside the list item. This sort of artificial benchmark doesn't mean anything, you should know that. What you need to measure is how the stuff is really used to see the real effect on cache and generated code. The we can talk about timing, slowdown & performance. Have you done this and seen a significative difference? (I did it, of course, and there wasn't anything significative, all witihn the noise of the measurements). Also, in November while I was fixing the problem with empty blocks, Linus himself said about the ptrlist macros: "Some of those inlines look large enough that I wonder how much sense they make as inlines any more" And indeed, having all those levels of looping inline/in macros is quite questionnable regarding the quality of the code that can be generated and impact on i-cache. It was Linus' remark and combined the issue and the complexity/subtility which motivated me to see what else can be done with these lists. But well ... -- Luc -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
