From: bc@nospicedham.freeuk.com   
      
   On 20/01/2018 12:33, Bartc wrote:   
   > On 20/01/2018 05:26, Alexei A. Frounze wrote:   
      
   >> I found that NASM is bad with not large inputs but many   
   >> jumps. It optimizes them for size and is quite slow there.   
      
   > Regarding optimising for short jumps: my assembler at first did no   
   > optimising for forward jumps, they always used 32-bit offsets. But I   
   > couldn't see much difference in performance of the EXEs: one app might   
   > be 1-2% faster with Nasm, another 1-2% slower. But I still have some   
   > optimisations to do.   
      
   I've added some optimised short jumps to my assembler. (It just looks to   
   see if the target label is within 8 instructions ahead, and assumes the   
   offset will be under 128 bytes. That's based on a maximum instruction   
   size of 15 bytes.)   
      
   One test program where Nasm had been 2% faster, now both assemblers'   
   executables run at the same speed.   
      
   Another program, my assembler's executable is 3% faster than Nasm's.   
      
   Maybe other tests will make Nasm come out on top. But it does sound like   
   the benefits of Nasm's multiple passes are overrated.   
      
   On the 120KLoC module (I can't test that app as it's too fast to   
   compare), Nasm's multiple passes were making it take over 50% longer to   
   assemble, from 26 to 41 seconds.   
      
   (I have to say my assembler is much simpler, supports fewer   
   possibilities, and only assembles a subset of all possible x64   
   instructions, compared to Nasm. But for the purpose of assembling the   
   code I generate or write inline, it does the job much better than Nasm.)   
      
   --   
   bartc   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)