Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Parsing timestamps?
Date: Thu, 17 Jul 2025 12:54:29 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 60
Message-ID: <2025Jul17.145429@mips.complang.tuwien.ac.at>
References: <1f433fabcb4d053d16cbc098dedc6c370608ac01@i2pn2.org> <2025Jul13.110141@mips.complang.tuwien.ac.at> <2d6811168025a74b3ff51a78efb75947d36a0146@i2pn2.org> <2025Jul14.080413@mips.complang.tuwien.ac.at> <063d4a116fb394a776b1e9313f9903cf@www.novabbs.com> <2025Jul14.095004@mips.complang.tuwien.ac.at> <a449857495e02b4d35627f9f31d37fd8@www.novabbs.com> <2025Jul16.132504@mips.complang.tuwien.ac.at> <2025Jul16.173926@mips.complang.tuwien.ac.at> <20250717101400.000074f9@tin.it>
Injection-Date: Thu, 17 Jul 2025 15:17:22 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c2d2c8bba04bb4cac67345297db9df81";
	logging-data="1446876"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/N+s2SPXyE17MkVstxb8rH"
Cancel-Lock: sha1:9ea6KmvwABu15ATiFtP4HGnvdyc=
X-newsreader: xrn 10.11

peter <peter.noreply@tin.it> writes:
>Ryzen 9950X
>
>        lxf64
>     5,010,566,495     NAI cycles:u
>     2,011,359,782     UNR cycles:u
>       646,926,001     REC cycles:u
>     3,589,863,082     SR  cycles:u
>
>        lxf64    =20
>     7,019,247,519     NAI instructions:u      =20
>     4,128,689,843     UNR instructions:u       =20
>     4,643,499,656     REC instructions:u=20
>    25,019,182,759     SR  instructions:u=20
>
>
>        gforth-fast 20250219
>     2,048,316,578      NAI cycles:u
>     7,157,520,448      UNR cycles:u
>     3,589,638,677      REC cycles:u
>    17,199,889,916      SR  cycles:u
>
>        gforth-fast 20250219
>    13,107,999,739      NAI instructions:u=20
>     6,789,041,049      UNR instructions:u
>     9,348,969,966      REC instructions:u=20
>    50,108,032,223      SR  instructions:u=20
>
>        lxf
>     6,005,617,374      NAI cycles:u
>     6,004,157,635      UNR cycles:u
>     1,303,627,835      REC cycles:u
>     9,187,422,499      SR  cycles:u
>
>        lxf
>     9,010,888,196      NAI instructions:u
>     4,237,679,129      UNR instructions:u=20
>     4,955,258,040      REC instructions:u=20
>    26,018,680,499      SR  instructions:u

>lxf uses the x87 builtin fp stack, lxf64 uses sse4 and a large fp stack=20

Apparently the latency of ADDSD (SSE2) is down to 2 cycles on Zen5
(visible in lxf64 UNR and gforth-fast NAI) while the latency of FADD
(387) is still 6 cycles (lxf NAI and UNR).  I have no explanation why
on lxf64 NAI performs so much worse than UNR, and in gforth-fast UNR
so much worse than NAI.

For REC the latency should not play a role.  There lxf64 performs at
7.2IPC and 1.55 F+/cycle, whereas lxf performs only at 3.8IPC and 0.77
F+/cycle.  My guess is that FADD can only be performed by one FPU, and
that's connected to one dispatch port, and other instructions also
need or are at least assigned to this dispatch port.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2025 CFP: http://www.euroforth.org/ef25/cfp.html