| Deutsch English Français Italiano |
|
<vsaeka$uhvh$1@paganini.bofh.team> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!news.mixmin.net!news.swapon.de!news.in-chemnitz.de!3.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: antispam@fricas.org (Waldek Hebisch)
Newsgroups: comp.os.vms
Subject: Re: ISO: The Eiffel OO programming language and IDE, on VMS
Date: Sun, 30 Mar 2025 03:43:08 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vsaeka$uhvh$1@paganini.bofh.team>
References: <j7jutjdo007jkfp956ofp846ecb0nfpr32@4ax.com> <vrnmla$155vg$1@dont-email.me> <vrvbb2$arv9$1@dont-email.me> <87v7rwjs3e.fsf@lucy.meyer21c.net> <vs0qdf$1mlt9$1@dont-email.me> <vs47iu$sgia$1@dont-email.me> <vs487f$trca$1@dont-email.me> <vs6sgr$3bt6n$3@dont-email.me> <vs9djd$nov4$1@paganini.bofh.team> <vsa2et$2jdbi$5@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 30 Mar 2025 03:43:08 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="1001457"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 4419
Lines: 71
Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 3/29/2025 2:19 PM, Waldek Hebisch wrote:
>> Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
>>> On 2025-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> or:
>>>> - people use a different backend than LLVM (GCC, custom, whatever)
>>>
>>> If anyone knows of a serious backend code generator other than LLVM
>>> or GCC, please feel free to point me at it. :-)
>>
>> Depends what you consider serious (and what "backend" means).
>> There is bunch of compilers that use their own backend,
>> for example optimized Ocaml or SBCL Lisp. If you aim at
>> highest possible speed, regardless of language, then they
>> can not compete. If you look at native performance for
>> relevant languages, then they are top performers (there are
>> Lisp compilers which generate code via translation to C,
>> resulting speed is lower than obtained using SBCL).
>>
>> Note that context was porting languages, "classic"
>> languages are covered by VSI, so relevant things are
>> backends for more exotic languages. There was recent
>> trend to adopt LLVM in such cases, and Julia seem to
>> be prominent example of language dependent on LLVM.
>> But more popular approach seem to be via custom
>> backend or via C. For example Haskell folks some time
>> ago said that LLVM does not really give them advantages
>> compared to going via C, and C way is easier.
>
> For true general purpose languages, then highly
> optimizing is a must have.
I think it is more complicated. In era of commercial C
compilers comparing speed of code generated by two different
compilers one could get factor like 1.5 or even 2. Do
you consider both as highly optimizing? And there were
customers paying for compiler that generated slower code.
Currently free avalability of gcc and clang limits use of
other C compilers. But advantages of other language may
be deemed more important than modest difference in speed.
Also, if you try to mimic style from other language in C
code, you may end up with slower code than using compiler
for other langage: both Ocaml and SBCL Lisp optimize and
optimization have significant effect for idomatic code in
respective languages.
> But for many less general purpose languages then
> it is not so important.
>
> The typical business application is not CPU bound.
> There are some very widely used languages out
> there where most use interpretation despite
> JIT compilation being available. Because the speed
> difference does not matter for most.
>
> There are also embedded applications where
> real time characteristics are essential but
> speed does not matter.
>
> If a language is more specialized and targeting
> a market where speed is not important, then the
> compiler backend does not need to be state of
> the art.
Ocaml have also interpetive backend, that one is for uses
where speed is not important. Optimized Ocaml and SBCL
are used in situations were speed is important, but
writing program in C would be too expensive.
--
Waldek Hebisch