SBCL is retarded

Why

    (while (/= i e)
      #.`(progn ,@(loop as i below 16 append '((setf (aref d i) color) (incf i)))))
    (format nil "")
    (dotimes (j (- l e)) (setf (aref d (f+ i j)) color))
runs at 545,960 processor cycles (according to TIME), but

    (while (/= i e)
      #.`(progn ,@(loop as i below 16 append '((setf (aref d i) color) (incf i)))))
    (dotimes (j (- l e)) (setf (aref d (f+ i j)) color))
takes 2,221,300 processor cycles? does SBCL rolls the loop back or what? why inserting noise statements increases drawing speed?

>>1
Yes. And there is no mistake: I can see with my eyes the jump sprite movement with addition of useless (format nil "").

https://bugs.launchpad.net/sbcl/+bug/554190

SBCL does not do any classic loop optimizations (e.g. unrolling), let alone any of the higher-level transforms described in Allen and Kennedy. SBCL does rudimentary loop analysis to aid register allocation and aligning loop heads -- but that's it. In this case it's particularly sad as the (= 1 1) is optimized away -- so the loop is quite breathtaking:

; B0: L0: 4883C108 ADD RCX, 8
; B4: L1: 483B0D25000000 CMP RCX, [RIP+37]
; BB: 7EF3 JLE L0

UNOPTIMIZING OPTIMIZING COMPILERS

(libc::memset_pattern4 (sb-sys:vector-sap d) (sb-sys:vector-sap v) (* l 4))
Does the same in about 323,096 processor cycles. Had SBCL done basic optimizations, its speed would have been comparable to GCC.

bampu pantsu