From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.devel Subject: Re: Add more supported primitives in libgccjit IR (was: Shrinking the C core) Date: Mon, 21 Aug 2023 09:42:37 +0000 Message-ID: <77daee02cf1ba0db70c1@heytings.org> References: <20230809094655.793FC18A4654@snark.thyrsus.com> <87msym9i4r.fsf@dataswamp.org> <877cpp914t.fsf@localhost> <83fs4dwwdo.fsf@gnu.org> <874jkt90a5.fsf@localhost> <87y1i57jqi.fsf@localhost> <87pm3h7h8k.fsf@localhost> <87h6ot7cf3.fsf@localhost> <87edjx7c0b.fsf@localhost> <831qfxw2cx.fsf@gnu.org> <87v8d95918.fsf@localhost> <87zg2lav4b.fsf@yahoo.com> <87sf8d57wf.fsf@localhost> <87r0nxatu1.fsf@yahoo.com> <87pm3h56ig.fsf@localhost> <87edjxarhz.fsf@yahoo.com> <87edjw4uw4.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16709"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Po Lu , Andrea Corallo , Eli Zaretskii , ams@gnu.org, incal@dataswamp.org, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 21 11:43:42 2023 Return-path: Envelope-to: ged-emacs-devel@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 1qY1Rm-00049U-78 for ged-emacs-devel@m.gmane-mx.org; Mon, 21 Aug 2023 11:43:42 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qY1Qv-0001Uw-JE; Mon, 21 Aug 2023 05:42:49 -0400 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 1qY1Qq-0001UT-Sb for emacs-devel@gnu.org; Mon, 21 Aug 2023 05:42:45 -0400 Original-Received: from heytings.org ([95.142.160.155]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qY1Qo-0007hx-0z; Mon, 21 Aug 2023 05:42:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1692610957; bh=gkEhgGPy1vhs2djs+eaxh+IVp/nLyevOeBGkukwCLwM=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=yNw4hDbjZlRXPKP6BPz8mjHGOTqQOVHuOeHmJRFvGJybWNDyhUcqA3If26kY+u/nh 47FNfJND8EajCe8I3URSOH8BQFdcrvWkHebiTE7eugR2vyA5bPix1Y23QStdiDjIKB evdkSEU3OwTh86v2dqw75h3dqCuLS4bb3vDuiMyj+x1ZQMEn7SquBReen1gGCnWswF EbBj4et5QNXNhVbOQ5jdpJh3Zve5DvjT1c2NC0cuCNQY2sCdcNxDXADITrTPVLQe9g rtCSPby9Ix7iTV4ZY5bs2CxwaE34CeYUXesHBrk6n40Y+WDOveQypEE/RUJr3pTfhj oRofYbtdWdrRg== In-Reply-To: <87edjw4uw4.fsf@localhost> Received-SPF: pass client-ip=95.142.160.155; envelope-from=gregory@heytings.org; helo=heytings.org 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:309045 Archived-At: > > Just to get something going, I executed > https://elpa.gnu.org/packages/elisp-benchmarks.html benchmarks and > looked into the primitives that take significant amount of time: > > 3.85% emacs emacs [.] arith_driver > 2.62% emacs emacs [.] Fgtr > 2.31% emacs emacs [.] check_number_coerce_marker > 2.24% emacs emacs [.] Fmemq > 2.20% emacs emacs [.] Flss > 1.56% emacs emacs [.] arithcompare > 1.12% emacs emacs [.] Faset > 1.10% emacs emacs [.] Fcar_safe > 0.97% emacs emacs [.] Faref > 0.94% emacs emacs [.] Fplus > 0.93% emacs emacs [.] float_arith_driver > 0.58% emacs emacs [.] Feqlsign > > We may consider directly supporting some of these functions in native > compile libgccjit IR code to get rid of runtime type checks. > I'm not sure elisp-benchmarks are representative enough of actual Elisp code, but this is an excellent example of what Alfred tries to convey. Look at data.c:arith_driver. You'll see that it's essentially a function which dispatches the handling of its arguments depending on their type: if the arguments are integers, do something, else if the arguments are floats, do something, else if the arguments are bignums, do something. Now look at data.c:Fgtr or data.c:Flss. You'll see that it calls arithcompare_driver, which calls arithcompare, which again dispatches the handling of the arguments depending on their types: integer, float, bignum. These integer/float/bignum types are not known at compilation time, because Elisp is a dynamically typed language, which means that the type of an object can change over its lifetime, an object could be an integer at some point of time, and later a float, and later again a bignum. In a statically typed language, these type dispatch operations can be bypassed, because it is known at compilation time that the arguments are, say, integers, and that we can simply call the "add" instruction to compute their sum. So, in a statically typed language, adding two integers takes a single CPU cycle. In a dynamically typed language, it can take many CPU cycles. And of course, using a JIT compiler does not magically transform a dynamically typed language into a statically typed one: you still need to do these dynamic dispatches.