From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Psionic K Newsgroups: gmane.emacs.help Subject: Re: Identifying sources of allocations in a toy Mandelbrot package Date: Fri, 19 Jan 2024 18:19:55 +0900 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37589"; mail-complaints-to="usenet@ciao.gmane.io" Cc: incal@dataswamp.org, Eli Zaretskii To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 19 10:20:56 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 1rQl3Y-0009Vq-91 for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 19 Jan 2024 10:20:56 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rQl2q-0003w5-AX; Fri, 19 Jan 2024 04:20:12 -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 1rQl2o-0003vu-5J for help-gnu-emacs@gnu.org; Fri, 19 Jan 2024 04:20:10 -0500 Original-Received: from mail-yb1-xb34.google.com ([2607:f8b0:4864:20::b34]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rQl2m-0003sF-9r for help-gnu-emacs@gnu.org; Fri, 19 Jan 2024 04:20:09 -0500 Original-Received: by mail-yb1-xb34.google.com with SMTP id 3f1490d57ef6-dc24f395c84so477263276.1 for ; Fri, 19 Jan 2024 01:20:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=positron.solutions; s=google; t=1705656006; x=1706260806; darn=gnu.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=aUbEf6+6Z2UR0oWYSWEa+NaV/IFYM68BlATfQYrkXug=; b=nbt4Hl/n80wALHiKj8X2ncyUuNJhhsFZk5vsax6SqsJSUCVPkBU33Wj0aiFd3/ZhAk YAmY8t2MXkduFLwX2xYKw3AHN7GkirCTPU1JsIs16/KKhahZfsRpFRFTwUi8q+VbURYM B8+g0MNzApx5oCNR+7TWJ+O0TYIFCE2biYA3NOgK6Iu+Ej1ZWBpoqqUjGNmameArOLBx 9/zGKBtxakowlUoP9j5UYgkm36BMSFZu4nCosJQDGYjuH3TiqMu7QKpbL5k7Z+f5sVQ7 UqgCpp6T/RwLeGpxYNMIK6U08eMkoJdDoFJzJglFm6Niw2bAxsw/mNgFwOOfMW+jXUWi ASQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705656006; x=1706260806; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=aUbEf6+6Z2UR0oWYSWEa+NaV/IFYM68BlATfQYrkXug=; b=qkM/mDeR/2wlTrXNdxIRTZ/PGZPKjR9aqbZspETzDa+3JKU1vLnzk8RDXHsPH5fUXV I0eGrISUMc9Tto3ulLdXFN0B6EVxWebaRwsxz5Rphr8mVZ01BrjcExYnrOvQnXXioKaE 4JgINPbQYSfiVgAf2UxOonJuXY+3kYWZPD5n1HMRZEtwSqOrbK28fNGy6Bp2SryorQjY plY1kqIAvXZoBphqTdolk7ICSadJBWHhp9NiemRzfIN5erW4uYB5JnNBqQDjNZGr20CZ i2HZVhEFo285IQgP9xbTYLdYcbgKlACMG4dMJG53CxGfXlwOwQmuo3AJf6xFxohhhfE4 rG8g== X-Gm-Message-State: AOJu0Yz80DCiT39LjYL5GtTGoHi3aBXK66F19G4ZcJ7jiQ9eTplLFQ8C Ije98FVn9YYZmkhEpOzSz+ecA/lUsKtai1yA4OH8Vjt3bkvdTmXu7XojDk1ZuSX+bGpLxkAs5oV jrpLeWFEKQXJCJbmGwO6P9AjSGKbf5/4g3qp0iAANasfu4oDHq+s= X-Google-Smtp-Source: AGHT+IFQtssjGCao242IsdGhquCN+4Rpn/Ul2TYh7by7jEvx0mfgkQKh2DcNjsC2LXEDpQ4C3XU4dao34fCF1JOBVXE= X-Received: by 2002:a5b:ccf:0:b0:dbf:3d61:8d03 with SMTP id e15-20020a5b0ccf000000b00dbf3d618d03mr471918ybr.28.1705656006197; Fri, 19 Jan 2024 01:20:06 -0800 (PST) Received-SPF: pass client-ip=2607:f8b0:4864:20::b34; envelope-from=exec@positron.solutions; helo=mail-yb1-xb34.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:145753 Archived-At: Most importantly to my question, how can I identify sources of consing without just knowing which functions and macros pathologically cons? Is there a way to allow usage of stack by the byte or native compiler? > You have a pretty big vector The vector is allocated once and not on the same scale as usage, measured by profiling or by resident memory in top. If I let Emacs run with no GC, it will consume about 10GB before it starts swapping and becomes unresponsive until I kill it. > and a lot of nested iteration I would have expected this to consume only stack memory, but it seems that neither native compiled nor bytecode can use memory in a stack-like way? I'm not sure what the Elisp manual on stack allocated objects means for native or byte compiled functions. > cl-psetq conses. After removing this for a combination of setq's and then removing two unnecessary `cl-dotimes` expressions that used no CL features, I've seen a second-run reduction down to about 8-9s. The first run is quite a bit longer. Although both runs GC 4-5 times, the first run of an Emacs session is about 35s versus 8s for a second run. `gc-elapsed' after the first run goes from near zero to 33.7s. The result is still on the same order of magnitude in terms of memory usage. The only behavior consistent with earlier memory profiling I did is if every single floating point value ever calculated lives on a unique piece of heap until GC'd. It as if heap is consumed in a straight line and there is no stack memory. Perhaps concerning is that Emacs continues to consume the same resident memory, about 2.1GB, indefinitely after the first run. Is this simply expected from a sprinkling of objects that Emacs cannot GC and therefore never give back memory? Is this unique to floating points? Do I still have latent consing in this version? Thanks in advance. ;;; mandelbrot.el --- Mandelbrot -*- lexical-binding: t; -*- ;;; Commentary: ;; Render's Mandelbrot set. ;;; Code: (eval-when-compile (require 'cl-lib)) ;;;###autoload (defun mandelbrot () "Render a mandelbrot." (declare (speed 3)) (interactive) (pop-to-buffer (get-buffer-create "*mandelbrot*")) (let ((gc-cons-threshold (* 800000 2048)) (gc-cons-percentage 1.0)) (let* ((cx) (cy) (zr) (zi) (v) (out) (zrt) (inhibit-modification-hooks t) (w 1600) (h 1200) (d 256) (output (make-vector (* w h 3) 0)) (idx 0) (x0 -2.5) (y0 -1.5) (dx 4.0) (dy 3.0) (dxp (/ dx w)) (dyp (/ dy h))) (fundamental-mode) (erase-buffer) (set-buffer-multibyte nil) (insert (format "P6\n%d %d\n255\n" w h)) (dotimes (y h) (dotimes (x w) (setf cx (+ x0 (* dxp x))) (setf cy (+ y0 (* dyp y))) (setq zr 0) (setq zi 0) (setq v (cl-dotimes (v d d) (if (> (+ (* zr zr) (* zi zi)) 4) (cl-return v) (setq zrt (+ (* zr zr) (- (* zi zi)) cx)) (setq zi (+ (* (* zr zi) 2) cy)) (setq zr zrt)))) ;; samples that hit 256 wrap in the graphic to display as zero ;; exponential 0.8 enhances contrast a bit (setq out (floor (* 256 (expt (/ (float v) d) 0.8)))) (aset output idx out) (aset output (+ idx 1) out) (aset output (+ idx 2) out) (setq idx (+ idx 3)))) (insert (concat output)) (image-mode)))) (provide 'mandelbrot) ;;; mandelbrot.el ends here.