All of lore.kernel.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Kautuk Consul <kconsul@linux.vnet.ibm.com>
Cc: Thomas Huth <thuth@redhat.com>,
	aik@ozlabs.ru, groug@kaod.org, slof@lists.ozlabs.org,
	kvm-ppc@vger.kernel.org
Subject: Re: [PATCH v2] slof/engine.in: refine +COMP and -COMP by not using COMPILE
Date: Fri, 23 Feb 2024 15:04:56 -0600	[thread overview]
Message-ID: <20240223210456.GP19790@gate.crashing.org> (raw)
In-Reply-To: <Zdg0O/67vQIip7hN@li-a450e7cc-27df-11b2-a85c-b5a9ac31e8ef.ibm.com>

On Fri, Feb 23, 2024 at 11:29:23AM +0530, Kautuk Consul wrote:
> > > difference (e.g. by running the command in a tight loop many times)?
> Running a single loop many times will not expose much because that loop
> (which is NOT within a Forth colon subroutine) will compile only once.
> In my performance benchmarking with tb@ I have put 45 IF-THEN and
> IF2-THEN2 control statements that will each compile once and reveal the
> difference in compilation speeds.

All of this is only for things compiled in interpretation mode anyway.
Even how you get the source code in (read it from a slow flash rom in
the best case!) dominates performance.

You do not write things in Forth because it is perfect speed.  Write
things directly in machine code if you want that, or in another high-
level language that emphasises optimal execution speed.  The good things
about Forth are rapid prototyping, immediate testing of all code you
write, simple compact code, that kind of goodness.  Ideal for (system)
firmware!


Segher

  reply	other threads:[~2024-02-23 21:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-02  5:15 [PATCH v2] slof/engine.in: refine +COMP and -COMP by not using COMPILE Kautuk Consul
2024-02-12  9:28 ` Kautuk Consul
2024-02-23 20:57   ` Segher Boessenkool
2024-02-26  4:39     ` Kautuk Consul
2024-03-07  6:33       ` Kautuk Consul
2024-03-18  5:12         ` Kautuk Consul
2024-05-22  9:04           ` Kautuk Consul
2024-05-27 12:33             ` Alexey Kardashevskiy
2024-05-28  4:02               ` Kautuk Consul
2024-02-22  7:38 ` Kautuk Consul
2024-02-22  9:04   ` Thomas Huth
2024-02-22 11:46     ` Kautuk Consul
2024-02-23  5:59       ` Kautuk Consul
2024-02-23 21:04         ` Segher Boessenkool [this message]
2024-02-26  4:32           ` Kautuk Consul
2024-02-26  4:43             ` Kautuk Consul
2024-02-26  6:47               ` Kautuk Consul
2024-02-26  6:59                 ` Kautuk Consul

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

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

  git send-email \
    --in-reply-to=20240223210456.GP19790@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=aik@ozlabs.ru \
    --cc=groug@kaod.org \
    --cc=kconsul@linux.vnet.ibm.com \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=slof@lists.ozlabs.org \
    --cc=thuth@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.