From: cross@spitfire.i.gajendra.net
In article ,
Waldek Hebisch wrote:
>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.
SBCL and OCaml aren't great examples.
SBCL is fast in large part because Google is paying Doug Katzman
to make it fast, and Doug is a really smart guy. When he
started working on it, it generated code that wasn't great (it
was ok for RISC-y style ISAs, not so much for x86). Google is
invested in this because QPX is written in Common Lisp and uses
SBCL, and is a major consumer of CPU cycles across the Google
fleet, where small, incremental improvements can mean a lot. I
made a change to QPX that saved some smallish (single digit)
precentage of CPU type, and that saved the equivalent of
thousands of CPU cores in data centers distributed across the
globe.
OCaml is fast because Jane Street invests in it heavily. Cf
some of the work that Yaron Minsky has presented on modes, and
multithreading the runtime.
A much more interesting example is something like MLton, for
SML.
- Dan C.
--- SoupGate-DOS v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
