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: References: <87v7rwjs3e.fsf@lucy.meyer21c.net> 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 wrote: > On 3/29/2025 2:19 PM, Waldek Hebisch wrote: >> Simon Clubley wrote: >>> On 2025-03-27, Arne Vajhøj 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