[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Concurrency via isolated process/thread

From: Eli Zaretskii
Subject: Re: Concurrency via isolated process/thread
Date: Thu, 06 Jul 2023 17:08:02 +0300

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Thu, 06 Jul 2023 10:46:47 +0000
> Po Lu <luangruo@yahoo.com> writes:
> >> Emm. I meant memory allocation. AFAIK, just like GC allocating heap
> >> cannot be asynchronous.
> >
> > The garbage collector and object allocation can be interlocked, as with
> > everything else...
> I may be wrong, but from my previous experience with performance
> benchmarks, memory allocation often takes a significant fraction of CPU
> time. And memory allocation is a routine process on pretty much every
> iteration of CPU-intensive code.

Do you have any evidence for that which you can share?  GC indeed
takes significant time, but memory allocation? never heard of that.

> Is there a way to measure how much CPU time is spent allocating memory?

If you don't know about such a way, then how did you conclude it could
take significant time?

> Would it be of interest to allow locking objects for read/write using
> semantics similar to `with-mutex'?

Locking slows down software and should be avoided, I'm sure you know
it.  But the global lock used by the Lisp threads we have is actually
such a lock, and the results are well known.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]