unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Tomas Hlavaty <tom@logand.com>
To: Psionic K <psionik@positron.solutions>
Cc: Psionic K <psionik@positron.solutions>,
	help-gnu-emacs@gnu.org, incal@dataswamp.org,
	Eli Zaretskii <eliz@gnu.org>
Subject: Re: Identifying sources of allocations in a toy Mandelbrot package
Date: Sat, 20 Jan 2024 10:09:21 +0100	[thread overview]
Message-ID: <877ck4wev2.fsf@neko.mail-host-address-is-not-set> (raw)
In-Reply-To: <CADQMGAS8wZcZ5SU+37d_w=6O6eHSSZ2RsVVKbuTg8Ae6k0O08w@mail.gmail.com>

On Sat 20 Jan 2024 at 12:14, Psionic K <psionik@positron.solutions> wrote:
> I had presumed at a minimum that the compiler can re-use heap locations
> when it decides there's no risk.

garbage collector does this

> While the values will be in the heap, is
> there a way to destructively re-use heap locations so that we are not
> burning through all of the heap during iteration?  Do function calls re-use
> any heap space?  Does anything besides GC?   As it is, I can guess that
> every call to even + or * is creating a unique float that now exists on the
> heap until GC'd.

every lisp system represents data differently.
if a value is not immediate, it has to be consed.
maybe floating point numbers in emacs are not immediate.
it looks like emacs uses libgmp
and there are no special cases for IEEE representation.

for comparison, you could try your code on sbcl
and see how much better it gets just by using very sophisticated compiler

> Should I consider further modifications?

now it looks much nicer, well done

> (d 256) (dd 256.0)

this is fine, but it's used in single place,
could as well put the values directly in the code
without this let indirection

>                       (v 0) (not-escaped t))
>                   (while (and not-escaped
>                               (< v d))
>                     (if (> (+ (expt zr 2.0) (expt zi 2.0)) 4)
>                          (setq not-escaped nil)

not-escaped is not needed

                   (while (and (< v d)
                               (<= (+ (expt zr 2.0) (expt zi 2.0)) 4))



  parent reply	other threads:[~2024-01-20  9:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-19  9:19 Identifying sources of allocations in a toy Mandelbrot package Psionic K
2024-01-19 15:33 ` Tomas Hlavaty
2024-01-20  3:14   ` Psionic K
2024-01-20  3:37     ` Psionic K
2024-01-20  7:29     ` Eli Zaretskii
2024-01-20  9:09     ` Tomas Hlavaty [this message]
2024-01-20 10:03       ` Psionic K
2024-01-20 10:31         ` Eli Zaretskii
2024-01-26 23:36         ` Tomas Hlavaty
2024-01-27  1:07           ` Psionic K
2024-01-19 15:44 ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2024-01-27  9:25 Psionic K
2024-01-17 12:39 Psionic K
2024-01-17 12:58 ` Eli Zaretskii
2024-01-17 13:25 ` Emanuel Berg

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=877ck4wev2.fsf@neko.mail-host-address-is-not-set \
    --to=tom@logand.com \
    --cc=eliz@gnu.org \
    --cc=help-gnu-emacs@gnu.org \
    --cc=incal@dataswamp.org \
    --cc=psionik@positron.solutions \
    /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.
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).