all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: taylanbayirli@gmail.com (Taylan Ulrich Bayırlı/Kammer)
To: Alan Mackenzie <acm@muc.de>
Cc: Xue Fuqiao <xfq.free@gmail.com>,
	Christopher Allan Webber <cwebber@dustycloud.org>,
	Daniel Colascione <dancol@dancol.org>,
	bruce.connor.am@gmail.com, emacs-devel <emacs-devel@gnu.org>
Subject: Re: In support of guile-emacs
Date: Mon, 19 Oct 2015 23:01:21 +0200	[thread overview]
Message-ID: <87h9lmlgim.fsf@T420.taylan> (raw)
In-Reply-To: <20151019201224.GJ2438@acm.fritz.box> (Alan Mackenzie's message of "Mon, 19 Oct 2015 20:12:24 +0000")

Alan Mackenzie <acm@muc.de> writes:

> Hello, Taylan.
>
> [... snip ...]
>
>> I actually did some silly looping tests, but decided not to post them.
>> As far as the silly loops were concerned, there wasn't much difference.
>> Elisp's dotimes counts to ten million slightly faster than Guile's 'do'
>> with explicit counting (best approximation of 'dotimes' I could come up
>> with).  Guile iterates over a list of ten million elements faster.  It
>> didn't seem worthwhile to post; ....
>
> _Any_ real timings are better than hand waving.  Sophisticated testing
> can wait until things are ready for them.

You're right, that may have been overly hand-wavy...

>> .... silly loops are just silly loops.  (Incidentally, silly loops got
>> faster in Guile 2.2![0] Apparently non-silly loops also got faster
>> though.[1])
>
>> [0] http://wingolog.org/archives/2013/11/26/a-register-vm-for-guile
>> [1] http://wingolog.org/archives/2015/07/28/loop-optimizations-in-guile
>
>> And here some fun; when I tried to imitate dotimes with a "named let"
>> loop instead of 'do':
>
>> > ,time (let loop ((i 0)) (unless (= 10000000) (loop (+ i 1))))
>> ;; 0.002618s real time, 0.002607s run time.  0.000000s spent in GC.
>
>> What?!  That's way too fast.  Oh wait...
>
> That's a loop of 10,000,000 taking 2.618e-3 seconds.  That would be
> 2.6e-10 seconds per iteration, or approximately 4.0e9 iterations per
> second.  With a 4 GHz processor, that's 1 clock cycle per iteration.  It
> seems likely that some processing has been optimised away.
>
> When I run this in Emacs on my 2.6 GHz Athlong machine, with M-:
>
>   (time-it (let ((i 0)) (while (<= i 10000000) (setq i (1+ i)))))
>
> , this takes 1.8881s.  (`time-it' is my own macro, not a standard Emacs
> one.)  So, thus far, it's looking like Guile is a factor of ~700 faster.
> :-)

Oh oh, don't forget to byte-compile Elisp.  Was my first mistake too.

>> > ,optimize (let loop ((i 0)) (unless (= 10000000) (loop (+ i 1))))
>> $2 = (if #f #f)
>
>> Oh, heh.  A void 'do' loop doesn't get the same treatment because of
>> slightly different semantics, but a void named-let loop simply gets
>> eliminated out.
>
> Ah.  Shame.  How about calculating 1 + 2 + 3 + .... + 10,000,000 in a
> loop, then outputting it?  The sum (50,000,005,000,000) should easily fit
> into a 64-bit Lisp integer.
>
> This:
>
>   (time-it (let ((i 0) (s 0)) (while (<= i 10000000) (setq s (+ s i)) (setq i (1+ i))) (message "%s" s)))
>
> takes 3.389s on my machine.

Takes about 0.62s here, when byte-compiled.  The Guile variant:

(let ((i 0) (s 0))
  (while (<= i 10000000)
    (set! s (+ s i))
    (set! i (1+ i)))
  (format #t "~s" s))

Takes about 0.55s.  That's a very literal transcription of the function
to Scheme.  A more idiomatic version:

(let loop ((i 0) (s 0))
  (if (<= i 10000000)
      (loop (+ i 1) (+ s i))
      (format #t "~s" s)))

Takes about 0.50s.

BTW here's a timing function that automatically byte-compiles the
argument (side-effectfully if a symbol):

(defun time (function)
  "Return execution time of calling FUNCTION in seconds as a
float.  FUNCTION is byte-compiled automatically."
  (setq function (byte-compile function))
  (let ((start (current-time)))
    (funcall function)
    (let ((end (current-time)))
      (let ((time (time-subtract end start)))
        (+ (* (nth 0 time) (expt 2 16))
           (nth 1 time)
           (/ (nth 2 time) 1000000.0))))))

>> > Is the Guile VM, in fact, faster than the Emacs byte interpreter?  Who's
>> > done any measurements?  Surely the speed advantage/disadvantage of the
>> > Guile VM will depend, possibly a lot, on what program is being tested,
>> > but has anybody actually done any actual benchmarking?
>
>> I would also like to know, really.  I don't know what good benchmarks
>> might be that are both realistic and show the benefits of Guile's added
>> optimization passes and such.
>
> If Guile Emacs is advanced enough, timing the fontification of a file
> (say, ..../src/xdisp.c in our repository) would be a very meaningful
> timing.

I'm guessing that Guile Emacs isn't ready for that yet but, how can one
time that?

Taylan



  reply	other threads:[~2015-10-19 21:01 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-18 20:48 In support of guile-emacs Christopher Allan Webber
2015-10-18 23:12 ` Artur Malabarba
2015-10-19  1:07   ` Xue Fuqiao
2015-10-19 10:24     ` Alan Mackenzie
2015-10-19 10:27       ` David Kastrup
2015-10-19 14:14       ` Daniel Colascione
2015-10-19 14:35         ` Alan Mackenzie
2015-10-19 16:56           ` Taylan Ulrich Bayırlı/Kammer
2015-10-19 17:19             ` Alan Mackenzie
2015-10-19 18:50               ` Taylan Ulrich Bayırlı/Kammer
2015-10-19 19:03                 ` Dmitry Gutov
2015-10-19 19:49                   ` Taylan Ulrich Bayırlı/Kammer
2015-10-19 20:12                 ` Alan Mackenzie
2015-10-19 21:01                   ` Taylan Ulrich Bayırlı/Kammer [this message]
2015-10-20  9:53                     ` Alan Mackenzie
2015-10-20 20:09                       ` Taylan Ulrich Bayırlı/Kammer
2015-10-20 23:46                         ` John Wiegley
2015-10-21 12:54                         ` Taylan Ulrich Bayırlı/Kammer
2015-10-21 13:13                           ` Alan Mackenzie
2015-10-20  6:00                   ` David Kastrup
2015-10-19 14:50         ` David Kastrup
2015-10-19  8:22 ` Tom
2015-10-19  8:38   ` Andreas Schwab
2015-10-19  8:54     ` Tom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h9lmlgim.fsf@T420.taylan \
    --to=taylanbayirli@gmail.com \
    --cc=acm@muc.de \
    --cc=bruce.connor.am@gmail.com \
    --cc=cwebber@dustycloud.org \
    --cc=dancol@dancol.org \
    --cc=emacs-devel@gnu.org \
    --cc=xfq.free@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.