Hello Edmund, On Wed, Dec 21, 2016 at 2:26 AM, Edmund Grimley Evans < [email protected]> wrote:
> Are you dynamically generating code on Intel? Intel Core i5 > But presumably the dynamically generated code is not inside your loop? No, not for this benchmark. > However, if your > dynamically generated code is adjacent in memory to some data that > gets modified, then it could be (I have no idea how this stuff works > on Intel) that the processor thinks that the code may have been > modified, even though it hasn't been modified, and invalidates the > cache just in case. And this phenomenon would be very sensitive to the > precise layout. This could explain what's going on. On the other hand, I can reliably produce these slowdowns with my benchmark script, and it seems unlikely that the exact memory layout is the same between executions. > The solution might be to put the dynamically generated > code in a block of memory that is separately allocated with mmap. On > the other hand, if you're already doing that, probably this isn't the > explanation. > I wasn't, but this seems like the most promising possibility. I am 99% certain that normal Perl extensions, which are implemented using shared libraries, do not suffer from what I am seeing. Under the hood I'm pretty sure that they load their libraries using mmap. So, I tried modifying my allocator to use mmap for the dynamically generated code. Unfortunately, the slowdowns remain. Still, I think there is something to what you've suggested and plan to dig around a bit more. Thanks! David -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
