Front page | perl.perl5.porters |
Postings from October 2014
On Mon Jul 29 23:26:02 2013, tonyc wrote: > 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. There's been no follow-up, so closing the ticket. Tony --- via perlbug: queue: perl5 status: open https://rt.perl.org/Ticket/Display.html?id=115746Thread Previous | Thread Next