Front page | perl.perl5.porters |
Postings from July 2013
On Fri Nov 16 18:49:50 2012, bulk88 wrote: > On Fri Nov 16 18:31:40 2012, bulk88 wrote: > > This patch is also a syntax error in C++ because of cutting off the > > (unnecessary) null char in the initializers so as is it can not be > > applied. :-/ Other questions remain in this ticket without a conclusion. > The fix would be a INSTREQ_1,INSTREQ_2, INSTREQ_3, upto 8 I guess (after > that efficiency starts to go down hill on 64bit machine) macros since > variadic macros arent portable. That would also cut down in the large > amounts of ifdefs my patch has (and probably more if a solution is found > in this ticket). The new code introduced does produce some nice generated code, but it's unsafe (which could be worked around) and duplicative (which your macros could fix.) The main possible performance issue I can think of would be the extra memory access (probably from the internal cache) required on platforms that do allow unaligned memory acceses, potentially for both sides of the comparison. This may explain the mixed results from benchmarking. Where the name of the variable isn't one of the specials, the variable name probably *won't* match on the first letter (except for _), so the change won't produce a large performance win even ignoring the unaligned accesses. So I'm rejecting the patch on this ticket. Tony --- via perlbug: queue: perl5 status: open https://rt.perl.org:443/rt3/Ticket/Display.html?id=115746Thread Previous | Thread Next