unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: <tomas@tuxteam.de>
To: emacs-devel@gnu.org
Subject: Re: recursion to iteration macro
Date: Sat, 23 Mar 2024 14:25:02 +0100	[thread overview]
Message-ID: <Zf7YLmAIQdC56Wl3@tuxteam.de> (raw)
In-Reply-To: <87edc11baw.fsf@dataswamp.org>

[-- Attachment #1: Type: text/plain, Size: 2185 bytes --]

On Sat, Mar 23, 2024 at 11:40:07AM +0100, Emanuel Berg wrote:
> tomas wrote:
> 
> >>> At least for tail-call recursion, named-let will turn
> >>> recursive code into iterative code.
> >>>
> >>> But generally speaking, if you need to accumulate data on
> >>> the stack, then it becomes a lot more difficult.
> >> 
> >> Why is that so difficult, isn't a stack just a list with
> >> `push' and `pop'?
> >
> > Only usually *much* more efficient.
> 
> How do you propose the virtual stack be implemented?
> 
> The goal is to have recursion syntax but iteration execution
> transparently and seamlessly, other than that we will just
> make it as efficient as possible.

This is something the Schemes of the world have been doing
since mid to late 1970ies, with an ever increasing grade of
optimization. So much so that Scheme doesn't have (doesn't
need) iterative constructs.

As for the stack... best is to use the machine stack, of
course. When you've help from the hardware, better use it.

A locally contiguous stack plays into the hands of current
CPU architecture, where your CPU has to wait roghly for 100
cycles to get something out of RAM "out there" (here is an
old comparison of those times [0] -- I'd expect things to
have become even more extreme these days).

Chasing pointers along a list will kill your CPU cache and
clog your RAM interface (you're pulling in eight bytes for
each pointer) compared to a contiguous storage, where the
"next value" will most probably be in cache when you need
it.

Yes, modern architectures have learnt to (speculatively)
follow things which look like pointers. This has given us
Spectre [2] and other niceties.

If you want to see how such things are done in practice,
Andy Wingo's blog is a trove. Here[1]'s an older post where
he discusses Guile's (then) new register VM and how the
stack is handled for it.

So, in a nutshell, we already have roughly 50 years of
efficient recursion.

Cheers

[0] http://norvig.com/21-days.html#answers
[1] https://wingolog.org/archives/2013/11/26/a-register-vm-for-guile
[2] https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)

-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

  reply	other threads:[~2024-03-23 13:25 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-22 22:56 recursion to iteration macro Emanuel Berg
2024-03-23  7:12 ` Philip Kaludercic
2024-03-23 10:17   ` Emanuel Berg
2024-03-23 10:30     ` tomas
2024-03-23 10:40       ` Emanuel Berg
2024-03-23 13:25         ` tomas [this message]
2024-03-25 23:38           ` Richard Stallman
2024-03-26  5:40             ` tomas
2024-03-28 22:05               ` Richard Stallman
2024-03-29  6:36                 ` tomas
2024-03-30 22:37                   ` Richard Stallman

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=Zf7YLmAIQdC56Wl3@tuxteam.de \
    --to=tomas@tuxteam.de \
    --cc=emacs-devel@gnu.org \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).