Re: Performance assistance / advice
"Tim Bradshaw (as tfb at cley dot com)" <[email protected]>
| Newsgroups | gmane.lisp.lispworks.general |
|---|---|
| Message-ID | <[email protected]> |
On 12 Mar 2025, at 11:36, Yuri Davidovsky <[email protected]> wrote: > > I wasn't putting any judgment on any programming languages mentioned in my emails. I simply stated why trying to match C’s performance with Lisp (or any other dynamically typed language, although I did not mention other languages specifically) is a wild goose chase (in my opinion). I think that is indeed what people think. They think that because, in 1975, it was true: lisp compilers were simple-minded and marginal on the hardware people actually could afford, and C was a very good match for just that hardware. And it's somewhat true today as well, but for completely changed reasons. If you look at the assembly of the guts of the function which steps the state of the system in my program there is *no* dynamic typing there at all. The system knows that double floats are double floats and that fixnums are fixnums and so on. It is, in fact, a completely statically-typed program. C is, of course, a terrible match for what hardware looks like today, except insofar as modern hardware has been deformed to suit C (see the famous paper: https://dl.acm.org/doi/10.1145/3209212). The reason Lisp code is (perhaps) slower than the same thing written in C is, I think, simple: money. The computing market is worth trillions of dollars (spending is due to be something like 5 trillion dollars in 2025). Some small fraction of that money is going on making compilers for C and related languages fast on modern hardware: billions of dollars a year, perhaps. Every new feature of a processor will absolutely have an interface to it which can be used from C. Every new generation of a given design will have a team whose job is to make C compilers produce good code for it: both the vendor's native one where applicable but also others. In the last two years, there were, I think 10 people committing to SBCL, for instance. Perhaps there are 100 full-time-equivalents working on Lisp systems world-wide: I expect that is rather generous. That's why Lisp compilers produce code which is perhaps not quite as fast that produced by C-family compilers. It would be amazing if they did. OK, I think I've said everything I want to about this, for now. I may come back if I get around to a non-Lisp equivalent program. --tim _______________________________________________ Lisp Hug - the mailing list for LispWorks users [email protected] http://www.lispworks.com/support/lisp-hug.html