Carp – A statically typed Lisp, without a GC, for real-time applications

Post by pjmlp » Fri, Oct 15, 2021, 3:39 PM UTC

xxs wrote: post #87

pjmlp wrote: post #83

Earlier quoted context omitted.

Correction, one of Hotspot's GC implementations, there are plenty of Java implementations to chose from. Including ones with soft real time GC for performance critical deployments like PTC and Aicas. https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm Anyone picking a traditional JVM for such workloads is doing it wrong.

What I meant is that low latency GC is sort of a commodity/mainstream now. Not advising to use java or a specific JIT+Collector.

Post by TeMPOraL » Fri, Oct 15, 2021, 3:48 PM UTC

hcarvalhoalves wrote: post #89

TeMPOraL wrote: post #85

Earlier quoted context omitted.

S-expressions also enable proper macros, as long as it has them, it's already ahead of .

I guess so, I think my point is: are s-expression enough to qualify as a LISP?

Post by kragen » Fri, Oct 15, 2021, 4:17 PM UTC

naasking wrote: post #94

kragen wrote: post #90

Earlier quoted context omitted.

Reference counting is usually very expensive, because even reading a variable updates the reference count, and ending a scope involves testing the reference count of every variable defined inside the scope and conditionally deallocating the referent. Without reference counting, here's the end of a hairy function scope that deallocates 15 local variables and restores two callee-saved registers: 11a6: 48 83 c4 78 add $…

> Reference counting is usually very expensive, because even reading a variable updates the reference count There are many papers out there on how to elide most ref count operations on locals, and runtimes that use ref counting for automatic memory management typically defer ref count updates in various clever ways (like Nim IIRC). You give up some latency for significant throughput gains.

Post by aidenn0 » Fri, Oct 15, 2021, 4:35 PM UTC

pjmlp wrote: post #82

aidenn0 wrote: post #39

Earlier quoted context omitted.

Last I checked SBCL and CCL (both open source native compiled CL implementations) are quite a bit faster than Clasp. However, if you are primarily e.g. calling computational chemistry libraries written in C++, Clasp is the way to go. It's the only non-C++ language implementation I know of with actually usable C++ support.

C++/CLI comes to mind, as means to merge .NET and C++ worlds together.

Post by xxs » Fri, Oct 15, 2021, 5:00 PM UTC

jstimpfle wrote: post #98

tzs wrote: post #77

Earlier quoted context omitted.

> It could be I measured something wrong, but sometimes dozens of ms is what I got, and I concluded that non-blocking I/O avoids indeterminate blocking (such as reading from a TCP socket until the sender sent N bytes) but does it completely avoid taking in-kernel locks etc? Perhaps what you were seeing were occasions where the system decided during your system call that your processes' time slice had expired or some…

Preemption can happen even outside of system calls of course, but I guess my takeaway has been to just avoid calling into the system where a lot of things can happen that I don't really understand or control. That, plus setting my threads to high-priority and possibly pinning them to the right cores.