Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128651 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id C06BA1A00BC for ; Mon, 8 Sep 2025 11:46:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1757331916; bh=nhOvceOo7icwOMCN4G7tfE+Cr284eVtTulYlx/AI370=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=mx57t+jpCfzXanP06kU0H1t8TCRHRPlvQjLpkLw4R4VmKHSsjvO/4xkq3prtLvE17 gDqQ4isaZKDIzGcjBmgihaLFkISgIbZYxlaLF9Pj7HGTvCgtaHAAroPFz78QBngelS xdqCu8tCDQjNB7unAYeHMA+ZU7DjDvatL3BKUbgnNMJiFJVydP/MpBlfRlAzMMoVOI xe9pFZ0O/WmlWAbqhM0Gm7B3UtoAM9R4ZvNPXay9FWcU/Zcz8mexX/ryjQq39j1Ze7 AC8xG4SG0Zrt0LjZfevkrAEHF/gazDvNTABOPO55z3hDMyfQfPB1ulpcOs0NAjbXSf 9EVnI06XAsxRg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D52A018005B for ; Mon, 8 Sep 2025 11:45:15 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 8 Sep 2025 11:45:15 +0000 (UTC) Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-77264a94031so2956960b3a.2 for ; Mon, 08 Sep 2025 04:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757332002; x=1757936802; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mk8yMA9pQsjE4uO5VdmH6A36/RSXFcrQn0/jtfOtRqc=; b=DHa0JbMlrVOn7uwkbjvDxoSwUc40MsU502DX+yWA/m7MIGWNHbCvfyz3r/5cyJQgLI k0IPvyeGphjau09WcVhAwtnSuLbBSXJKXJoJfQsBdbHJOpXkuSKxLa7BQl9231kkm3Nt D+K5iKX6PUvnwPNPUjiQ22BnZZmxwhKu8oe+1nvp/VS8mIBPGO54UnMbRjca8L2SjqEU msEj+HtlypWjpZSi+FCv9AD6tjHQ7S+VTs54y/pqRejj4H7Tjv3VQMAR1Kvd8FZQqZJ9 RWRgwaiQOSQVwrG2nS3ttmUW5XUXV5CcFhwADUsbwesG8XfuMobzQ6k4mTgah0DQcwLD D/zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757332002; x=1757936802; 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=mk8yMA9pQsjE4uO5VdmH6A36/RSXFcrQn0/jtfOtRqc=; b=SuZJ+GLQbeJPeqjGknlGeIr6AixN9PpPJ+yI2+dhH96rOfX50UjMFybzPXlHqOV+qY YYKWZ4+MPXuSo+jSjCXmROK4byUk99Ll+minlHimJLai/RQdwcAQu1Re3MCQs96dgElp TE7gxWo4utQ0F9YT4R/W0nDTspbeRXv4ozfxDs3RH7ngTpN4nZdCHEoOIpS/26xm796d +NW3a1Io04UqupGKAB0eTc6foM63A/b0bH1KRVA3ceNYwX/scE1nSG798JGttytoVpgb rcKrUNAG9LAn9b/VFcQ5y1oJqRWK74dEbPUGut2h6QsXOf4XhPPXQKzMOfHrpc3KZaGW 14oQ== X-Forwarded-Encrypted: i=1; AJvYcCVLdcimw/wAdIj07so39KdLD4olbglY8g63BnAH6rXALKUlc1mnD9EUZ4UOq/k/JDIPCMjOhX/IM0Y=@lists.php.net X-Gm-Message-State: AOJu0YwrLMJcP6WqRtWNehkgaRw2xDIGsgNzo6NRLCyV+BrUtZpucclp b5Fy0A9TniOx2PM8m6nx721P96CAfOt2/hyGjf2I/aGNoyydCSi23GYG+OGrGpl8jrbL/aMZXjo v9ggNMkrptdGeGwg4+a2AiHKli71UDww= X-Gm-Gg: ASbGncvTOJfh9q9pPMhY67u6pVpZ+tZ//hUygAZEC+djs3OumQABnhuxqp9azxI+zA6 5tWeH22XBhTplGfsz4OCtnP8kTJtXG+7JArtU+86d6dmCaG7rfhgSE9C6uba62yf5kPTovyUrF4 4AnpgWpJ7egw+myYGjEaCEjFOgu9gJg+iz1RN1U7u/XRTFOIdpF4hzEqzxf1s/J20JwczV0ZC3x FCXgLUQAwPEarKlXw== X-Google-Smtp-Source: AGHT+IGWeeWsTjkK/IbDZRC0nIYaRBfHP4TNhbuQ2UB+6m4nYu4etMBySJkzXlDSpYQJbgReikyo+EDH3rOQTJ7ixrI= X-Received: by 2002:a17:902:ef52:b0:24a:9475:3dcb with SMTP id d9443c01a7336-25170c47735mr93242445ad.37.1757332001680; Mon, 08 Sep 2025 04:46:41 -0700 (PDT) Precedence: list list-help: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: <1756361767126.3727989781.4204927711@yahoo.de> <3b1bd29cd42074b499d38e10cb97bf42@bastelstu.be> <4db81c8b-64ee-4bf6-9134-c233c8cb3f71@varteg.nz> In-Reply-To: Date: Mon, 8 Sep 2025 13:46:30 +0200 X-Gm-Features: AS18NWDV61ggzRVdfMupWfYiSI084lBLpwrxYIbbU3I2cXF6fa5I1fiMtiDRioA Message-ID: Subject: Re: [PHP-DEV] [RFC] [Discussion] Add clamp function To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= Cc: Morgan , internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000b67216063e48bd92" From: kylekatarnls@gmail.com (Kyle Katarn) --000000000000b67216063e48bd92 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello 2025-08-29 at 15:12, Tim D=C3=BCsterhus wrote: > Hi > > On 8/29/25 04:42, Morgan wrote: > > Another part of the argument is "complexity", as brought up in the > > original proposal. I notice that the offered implementation of this > > function relies entirely on zend_compare(). > > I'm not finding the word =E2=80=9Ccomplexity=E2=80=9D in https://wiki.php= .net/rfc/clamp > or https://externals.io/message/115050. Can you link to the message you > are referring to? > > > reasons. The extra complication may not be worth it if there are only > > two or three values being compared (long and double are the first types > > zend_compare tries). > > I'm positive that the benchmarks will answer that question. > > Best regards > Tim D=C3=BCsterhus > I back-ported "not cost-effective when called multiple times" from the clamp v1, I think its author meant "compared to user-land implementation using min(max())" So I just did this benchmark: https://github.com/kylekatarnls/clamp-perf-test/actions/runs/17546601109/jo= b/49829393835 (following Tim's advice to use hyperfine for it). Summary is: php clamp.php ran 1.06 =C2=B1 0.02 times faster than php ternary.php 1.42 =C2=B1 0.03 times faster than php min-max.php Which means if everything is correct, then the current native implementation proposal is barely faster than a user-land function using ternary implementation. Using a user-land function and min(max()) is 42% slower. (See the files at the root of this repo: https://github.com/kylekatarnls/clamp-perf-test) Those numbers might have been better in the first implementation (which supported only int and float and it had no special case handling for NAN, so I guess it was even a bit faster this way). Anyway, I think the speed is probably not the main reason why we should add it. Maybe I would rather phrase the above result this way: - User-land implementation for clamp using ternary is notably faster than min(max()) user-land implementation -> but still the difference shouldn't be a concern for most people. - With the native implementation, you get (for no extra speed cost): -> NAN handling -> verification than min < max -> a standard way (framework/application can drop their own implementations and converge to the one propose by the language which will also be pretty similar with most implementations in other languages) So I guess I should arrange the note about cost-effectiveness, or maybe drop it all together. --000000000000b67216063e48bd92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello

2025-08-29 at = 15:12, Tim D=C3=BCsterhus <tim@baste= lstu.be> wrote:
Hi

On 8/29/25 04:42, Morgan wrote:
> Another part of the argument is "complexity", as brought up = in the
> original proposal. I notice that the offered implementation of this > function relies entirely on zend_compare().

I'm not finding the word =E2=80=9Ccomplexity=E2=80=9D in https://w= iki.php.net/rfc/clamp
or https://externals.io/message/115050. Can you link to the m= essage you
are referring to?

> reasons. The extra complication may not be worth it if there are only<= br> > two or three values being compared (long and double are the first type= s
> zend_compare tries).

I'm positive that the benchmarks will answer that question.

Best regards
Tim D=C3=BCsterhus

I back-ported "not cost-ef= fective when called multiple times" from the clamp v1, I think its aut= hor meant "compared to user-land implementation using min(max())"=

So I just did this benchmark:=C2=A0https:= //github.com/kylekatarnls/clamp-perf-test/actions/runs/17546601109/job/4982= 9393835 (following Tim's advice to use hyperfine for it).

Su= mmary is:
php clamp.php ran
1.06 =C2=B1 0.02 times faster than = php ternary.php
1.42 =C2=B1 0.03 times faster than php m= in-max.php

Which means if everythi= ng is correct, then the current native implementation proposal is barely fa= ster than a user-land function using ternary implementation.

Using a= user-land function and min(max()) is 42% slower.

(See the files at = the root of this repo:=C2=A0https://github.com/kylekatarnls/clamp-perf-test)

Th= ose numbers might have been better in the first implementation (which suppo= rted only int and float and it had no=C2=A0special case handling for NAN, s= o I guess it was even a bit faster this way).

Anyway, I think= the speed is probably not the main reason why we should add it. Maybe I wo= uld rather phrase the above result this way:
- User-land implementation = for clamp using ternary is notably faster than min(max()) user-land impleme= ntation
=C2=A0 -> but still the difference shouldn't be a concern= for most people.
- With the native implementation, you get (for = no extra speed cost):
=C2=A0 -> NAN handling
=C2=A0 -> verifica= tion than min < max
=C2=A0 -> a standard way (framework/applicatio= n can drop their own implementations and converge to the one propose by the= language which will also be pretty similar with most implementations in ot= her languages)

So I guess I should arrange the not= e about cost-effectiveness, or maybe drop it all together.


--000000000000b67216063e48bd92--