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: Sat, 27 Jan 2024 10:07:09 +0900 Message-ID: References: <87v87ps5gn.fsf@neko.mail-host-address-is-not-set> <877ck4wev2.fsf@neko.mail-host-address-is-not-set> <87wmrvd5va.fsf@neko.mail-host-address-is-not-set> 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="35042"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Psionic K , help-gnu-emacs@gnu.org, incal@dataswamp.org, Eli Zaretskii To: Tomas Hlavaty Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 27 02:08:15 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 1rTXB8-0008sR-HG for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 27 Jan 2024 02:08:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rTXAN-0003P6-8T; Fri, 26 Jan 2024 20:07:27 -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 1rTXAK-0003Of-Un for help-gnu-emacs@gnu.org; Fri, 26 Jan 2024 20:07:24 -0500 Original-Received: from mail-yb1-xb2e.google.com ([2607:f8b0:4864:20::b2e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rTXAI-0003sc-SD for help-gnu-emacs@gnu.org; Fri, 26 Jan 2024 20:07:24 -0500 Original-Received: by mail-yb1-xb2e.google.com with SMTP id 3f1490d57ef6-dc238cb1b17so1335322276.0 for ; Fri, 26 Jan 2024 17:07:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=positron.solutions; s=google; t=1706317641; x=1706922441; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HsjUJSdrlehVJ6od73O9AQxqB4bEzZlrPcpV102WFsk=; b=OuYc2sGHazB8FNQjeL2nzLvJLiCKx7vS1EZvy7qhNcvCzWiUAmXXG3N2PtuzDe7bQ1 VnpQ6bcdW3074SdgCo6vEH+5LhoQM1BTQZflVGZ8RRcGT+0becc3Y2uKpx1gWHvJ/EPB oRcFQ/lMP1iocQu1DepjAYxJBJiCMAyVnIsZETEzIyRxlw1gr5GK2+a2R7bt6hCtUPHm OZZpEugeL8imsjCzIAHxH+Y0/5PmyGEdqu30YoERGpHKfArs0Hjl9K1kVBtA6c82nHeB yrGc2d2NATAn+J5S6lQ9sx5vgWfn/mfLLouQh2yeZnlLF8jbUtmfieSvyhlzJjcoW3J1 DZrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706317641; x=1706922441; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HsjUJSdrlehVJ6od73O9AQxqB4bEzZlrPcpV102WFsk=; b=OnD05wA83PGj3Qkxx2zg0gytgJyh7CipY9zdmUTNScQqeERYn7wzx5l4P+LeqBfm7W c/8YKOB7RkfDVaeRuaYcZ3Q3TxCuGwRXS61npF4vqmuNdc7jlHnxFTFq1aexQiNdPnhE rnlpo+hrt4FL6PLAdlHCTat35KB0CelwgXx92pE7EfxLTVaOY+BXWbxD/PW2N2FIEN8K g9Ex+N+LBjABSco2oKgEoj0WQ9cBSV3mAaLEHN1GRzacI3sjNjKuofJob0uSXjXQzGnB xrPc+fz8Ylm7WFg+yhICB9X7VYgrep7ZbvnHbhOe80BDdBZ7FzbzF9jcZYQxKN57JkGV SItg== X-Gm-Message-State: AOJu0YxqVe2V9CW7ddK1ULIqKp3gyl5GutZiheTxAvN9+6IE+EsE8rEd mOmrgxNyHlqJadT29gWul79GcQGjmLJIkzxeOr+KA+4015higpRgAo+EfLje1gnd0UmQ1ZoBz5v OYXh6B6UDAa96CZ7+lOEbLVzdWASRHf0K43bODQ== X-Google-Smtp-Source: AGHT+IG8WJ+U3XIhrAOH/oNuCQmJbxO1MPdP0fE3OMcsfgiCHN9shc1FZqE0zAd4JzqK0e3LS+g1rwyeJoMWhgRijq0= X-Received: by 2002:a25:a4a6:0:b0:dc6:4aa8:d119 with SMTP id g35-20020a25a4a6000000b00dc64aa8d119mr762850ybi.77.1706317640737; Fri, 26 Jan 2024 17:07:20 -0800 (PST) In-Reply-To: <87wmrvd5va.fsf@neko.mail-host-address-is-not-set> Received-SPF: pass client-ip=2607:f8b0:4864:20::b2e; envelope-from=exec@positron.solutions; helo=mail-yb1-xb2e.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:145810 Archived-At: > I find it interesting that: > - native compilation improves so little compared to byte compilation. > - floating point calculations are very slow. > - emacs-lisp is very slow >From first principles and numbers I have seen so far, I can guess what's happening with little uncertainty. The Elisp interpreter must store all created conses and non-immediate values, however short-lived, into memory, converting every computationally intensive workload into a memory-intensive workload. None of this is freed for re-use between GC's, so in about 1/100th of a second, the memory controller is fully saturated and the CPU grinds to a halt. There are no workarounds for this using GC settings. The GC is non-generational, so frequent GC's must mark & sweep a lot of memory that is irrelevant to the currently running function. Frequent GC's will saturate the memory attempting to free small amounts that are relevant to the cache sizes. Furthermore, the GC is non-moving, resulting in fragmented reads and writes, so even for shorter computations, much of the loaded cache could be wasted. The sum of these behaviors is still faster than human speed, but almost pathalogically worst case usage of memory and cache, requiring multiple trips to RAM for almost all computations and limiting effective CPU register bandwidth to a small multiple of RAM. The programmer has few tools to increase computational density and all workloads are memory bandwidth limited. To remedy the most egregious behavior, which is that computations imply writes, we would take advantage of how functions usually throw away all of their intermediate values except the return value and implement stack-like behavior by compacting and freeing after cons thresholds calculated at call boundaries. We can still give this compacted memory back to our pathologically worst GC, but it will be less fragmented and there will be much less of it. A lot of this can be decided at compile time, and the compiler would write values that need to be preserved into one stack while writing other values at a different stack and re-setting the pointer. I can tell that this is not happening at all because otherwise the Mandelbrot would not be consuming multiple gigabytes of RAM for values that are thrown away at first use. Elisp could be exceptionally fast for small runs, especially with today's generous L1 sizes. That drops off as the interpreter and new data start hitting L2, L3, and then RAM. Any work on the compiler should focus on keeping memory from being entrusted to the existing GC because no amount of doing less work means anything if all work also consumes memory and freeing memory is hugely wasteful. Fixed point was neat! I didn't think to try that. Thanks for code!