From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tomas Hlavaty Newsgroups: gmane.emacs.help Subject: Re: Identifying sources of allocations in a toy Mandelbrot package Date: Sat, 20 Jan 2024 10:09:21 +0100 Message-ID: <877ck4wev2.fsf@neko.mail-host-address-is-not-set> References: <87v87ps5gn.fsf@neko.mail-host-address-is-not-set> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12046"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Psionic K , help-gnu-emacs@gnu.org, incal@dataswamp.org, Eli Zaretskii To: Psionic K Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 20 10:10:08 2024 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rR7Me-0002vJ-Fq for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 20 Jan 2024 10:10:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rR7M1-000496-OZ; Sat, 20 Jan 2024 04:09:29 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rR7Ly-00048m-JR for help-gnu-emacs@gnu.org; Sat, 20 Jan 2024 04:09:26 -0500 Original-Received: from logand.com ([37.48.87.44]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rR7Lx-0004Ec-2A; Sat, 20 Jan 2024 04:09:26 -0500 Original-Received: by logand.com (Postfix, from userid 1001) id 00B1B19E843; Sat, 20 Jan 2024 10:09:22 +0100 (CET) X-Mailer: emacs 28.2 (via feedmail 11-beta-1 I) In-Reply-To: Received-SPF: pass client-ip=37.48.87.44; envelope-from=tom@logand.com; helo=logand.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:145760 Archived-At: On Sat 20 Jan 2024 at 12:14, Psionic K 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))