libera/#commonlisp - IRC Chatlog
Search
17:24:21
aeth
That would actually be a selling point: if Common Lisp's FORMAT2 *requires* machine learning to function properly. It can be the first programming language with such a feature set.
18:25:55
NotThatRPG
Shinmera: Even English has "formula" and "formulae," "goose" and "geese," etc. English spelling, it transpires, was originally more influenced by history than by pronunciation, and that lingers.
20:19:44
nij-
Has anyone been forced to switch to a lower-level language because runtime performance is critical? Not that I'm facing this issue; I'm just curious to know what are some options in those scenarios.
20:28:55
varjag
i find that if the code makes no use of simd intrinsics or gpu there's hardly ever a need these days
20:31:11
nij-
My friends working for banks use python usually. But when performance is important, they have no choice but to use C++.
20:31:57
pjb
nij-: that has been the case with python. Also for bad support of threads. If I had used CL instead, I wouldn
20:32:40
pjb
nij-: they wouldn't happen as often. Quite heavy duty systems are written in Common Lisp.
20:41:34
Bike
python performance is kind of crap. other dynamic languages can be a lot faster than python. not just lisp.
20:50:40
Bike
cpython baked in some stuff they shouldn't have, and then they got used to just calling out to C to do anything important
20:53:28
gilberth
Are there any language features of Python that make compiling it particularly difficult?
20:58:59
pjb
gilberth: I don't know it enough, but I guess it's OO system is 100% run-time; but in CLOS too, you can change the classes and methods at run-time, so it wouldn't be harder than in lisp, other than in python the OO system is everything.
21:01:22
gilberth
pjb: Ok. Then perhaps they are lazy. I was just curious because I heard that argument that it would be hard not for the first time. And I know next to no Python and thus asked.
21:02:17
Bike
as for the actual question, i genuinely don't think there's much reason to drop into C or whatever for speed, but then i don't do AV processing. memory usage i'd be more worried about. i wouldn't try to run CL on a microprocessor
21:05:38
gilberth
Hmm, but with AV processing the parts of the application that burn 99% of your cycles are very limited. And even C can be too slow when you have a cheap and unsuited MCU and try to do what it barely can in terms of DSP.
21:08:58
gilberth
Otherwise, I am very tired of this kind of "language X faster than language Y" discussions. It rarely comes up that you only need to be fast enough.
21:09:25
Bike
It certainly gets repetitive, especially when we're talking about it divorced from any real use case
21:09:44
gilberth
varjag: 256KB SRAM is common with small MCUs these days. I wait for 1MB or 2MB to be common and then you can deploy CL on an MCU.
21:12:34
gilberth
I once was in the embedded industry. Some time ago. At which you could expect like 16KB SRAM. No way you could run any reasonable application written in Lisp on it. Would I still be in that industry, I'd try to get a reasonable Lisp onto the MCU. 256KB suffices for that, especially when you put your "static space" into flash, which is plenty.
21:14:02
gilberth
varjag: CLISP for instance was initially written for the Atari ST. It was happy with 1MB. It still is with around 2MB, if you really wish and you put some code aside at the flash. If not for the license, I'd start there.
21:14:45
gilberth
varjag: I didn't say Common Lisp. 256KB is plenty for some reasonable Lisp though.
21:18:00
gilberth
What I wanted to say, you could -- and this had been done -- Common Lisp into 1 or 2 MB.
21:24:12
gilberth
varjag: Doesn't change that CLISP still can do with 400KB .mem file, if you wish. On a 32-bit system. And the size of your text segment is not much of a concern as this could be put to flash, which usually is plenty.
21:26:53
gilberth
I don't advocate CLISP here, I just wanted to point out that you could make CL fit in 2MB easily, and in 1MB, if you must. I believe 1MB is the reasonable lower limit.
21:28:17
_death
both clisp and ecl can generate bytecode, I'm guessing one could write a tiny interpreter and runtime for a subset of it.. also, the L paper mentions running on a device with 1M RAM and a specially written operating system (in C) that occupied 16K
21:28:42
gilberth
varjag: My other point was that DSP is not 100% of your application. At that time I would have loved to have the higher application logic in Lisp and also with being able to use the interactive development style. But those 16KB I had was just too little, so I was stuck with C.
21:31:51
gilberth
The 8051 is horrible to work with. We never touched it. In 8-bit times we used an 8085 instead.