From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <tkoenig@netcologne.de>
Received: from cc-smtpout1.netcologne.de (cc-smtpout1.netcologne.de
 [89.1.8.211])
 by sourceware.org (Postfix) with ESMTPS id 5C2A43858D39;
 Sun, 26 Dec 2021 16:15:29 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5C2A43858D39
Received: from cc-smtpin3.netcologne.de (cc-smtpin3.netcologne.de [89.1.8.203])
 by cc-smtpout1.netcologne.de (Postfix) with ESMTP id E057412751;
 Sun, 26 Dec 2021 17:15:27 +0100 (CET)
Received: from [IPv6:2001:4dd7:eb03:0:7285:c2ff:fe6c:992d]
 (2001-4dd7-eb03-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de
 [IPv6:2001:4dd7:eb03:0:7285:c2ff:fe6c:992d])
 (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 cc-smtpin3.netcologne.de (Postfix) with ESMTPSA id 95A0511DB9;
 Sun, 26 Dec 2021 17:15:25 +0100 (CET)
Subject: Re: [PATCH] Make integer output faster in libgfortran
To: FX <fxcoudert@gmail.com>
Cc: gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org
References: <E3528FA0-68CE-445E-9E8D-E615911E59DF@gmail.com>
 <28ba2e92-065e-109f-b9e2-95b4609d0f66@netcologne.de>
 <18EA83FD-C127-4A5B-942B-224083947F9F@gmail.com>
 <43c60a0b-06b5-162b-bd5f-a7177cd76172@netcologne.de>
 <91272BC5-B108-4DB0-929C-EE437703F10B@gmail.com>
From: Thomas Koenig <tkoenig@netcologne.de>
Message-ID: <1471f348-1829-b253-86f3-47abb9182e25@netcologne.de>
Date: Sun, 26 Dec 2021 17:15:25 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <91272BC5-B108-4DB0-929C-EE437703F10B@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-NetCologne-Spam: L
X-Rspamd-Queue-Id: 95A0511DB9
X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW,
 RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS,
 TXREP autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: fortran@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Fortran mailing list <fortran.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/fortran>,
 <mailto:fortran-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/fortran/>
List-Help: <mailto:fortran-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/fortran>,
 <mailto:fortran-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Dec 2021 16:15:31 -0000

Hi FX,


>> (We could also do something like that for a 32-bit system, but
>> that is another kettle of fish).
> 
> We probably wouldn’t get a speed-up that big. Even on 32-bit targets
> (at least common ones), the 64-bit type and its operations (notably
> division) are implemented via CPU instructions, not library calls.

I'll look at this a bit more closely and report :-)

>  At this point, the output of integers is probably bound by the
> many layers of indirection of libgfortran's I/O system (which
> are necessary because of the rich I/O formatting allowed by
> the standard).

There are a few things we could do.  Getting a LTO-capable version
of libgfortran would be a huge step, because the compiler could
then strip out all of these layers.  The speed of

   character:: c


   write (*,'(A)', advance="no") c

could stand some improvement :-)

Regards

	Thomas