Prev: Amazing Video on How Computer Fashion Is Changing, Nice Work !!
Next: macro to expand into function body with declare at top
From: Giorgos Keramidas on 10 Mar 2010 13:20
On Tue, 9 Mar 2010 12:20:47 -0800 (PST), fortunatus <daniel.eliason(a)excite.com> wrote:
>> The idea is to pin whole Lisp process (image) to one CPU so that whole
>> process can do only one thing at a time.
>
> Meaning all the threads of the Lisp image must then share the same CPU
> - helping with race conditions since none will really be concurrent.

This simplifies things a bit, but it kind of defeats the point of having
multiple CPU cores, doesn't it?
From: Alex Mizrahi on 11 Mar 2010 08:29
SN> I don't see how pinning the whole process to one CPU will help
SN> here.
SN> Even if you don't have real parallel execution you still have to deal
SN> with concurrency. Thread A could be interrupted in the middle of its
SN> state changing operation and the thread B that tries to read this state
SN> could be scheduled.

I'm not saying it totally prevents race conditions, it merely greatly
reduces their probability.
Often state is inconsistent only for a brief moment in time, and chances
that thread will be interrupted precisely in that time is small.

Some race conditions can be prevented altogether. For example, INC <memory>
x86 instruction is not atomic in multi-core situations, but it will be
atomic if only one core is working, because you cannot interrupt thread
between instructions.

SN> And, by the way, why use multiple threads and then restrict yourself
SN> arbitrarily,

What do you mean "arbitrarily"? It is a trade-off between reliability and
performance. If performance is not a problem, you can get more reliability
this way.

SN> abandoning the most interesting advantage of
SN> multithreading (namely parallel execution)?

Well, for other advantages, maybe? Like, multiple threads of control?

E.g. you can have both console REPL, SWANK and HTTP-server listening at same
time, without any hasle. Technically, you can combine multiple listeners via
something like select(), but then they need to be aware of each other, while
with multithreading it just works. This way you can debug your web server,
I'd say it is a useful feature.

Another advantage is that when there is some long-running request, it won't
block other requests, and many other requests can be served with minimal
delays while long one is still calculating.
In GUI applications that means that some lengthy computations don't block
GUI and user doesn't go mad.

Multiple threads on one CPU might mean better performance if threads do a
lot of I/O -- then while one thread is blocked in I/O, other ones might do
something on CPU.

From: Captain Obvious on 11 Mar 2010 08:33
??>> Meaning all the threads of the Lisp image must then share the same CPU
??>> - helping with race conditions since none will really be concurrent.

GK> This simplifies things a bit, but it kind of defeats the point of
GK> having multiple CPU cores, doesn't it?

No, it doesn't. You can run more than one Lisp process, or you can run some
other processes. If your application works with database, application and
database can run concurrently and use multiple cores.
There are different situations...

From: Johan Ur Riise on 11 Mar 2010 13:49
Tim X <timx(a)nospam.dev.null> writes:

> When things begin to get a little more complex and flat text files no
> longer suffice, I've found things like Berkly DB to be pretty good.
> Sometimes, you may need to do a bit of optimisation to get best
> performance, but I've had really good results with large data sets of
> varying complexity using berkly db and the like. I've certailnly found
> it good to look at this before jumping to using a full SQL RDBMS

Anybody who has a need for persistent storage, and want something that is
not a SQL database, should take a look at cl-prevalence.

The ideas are:

1. Everything is kept in memory.
2. You change things by executing a transaction, which is a normal function
that is instrumented using the cl-prevalence system.
3. When you execute such function, its name and parameters are recorded in
a log.
4. When you start the system, the log is rolled forward.
5. There is provision for saving a snapshot and resetting the log.

Limits: It is one-process only, and data is limited to available memory.

http://common-lisp.net/project/cl-prevalence/






First  |  Prev  | 
Pages: 1 2 3 4 5 6 7
Prev: Amazing Video on How Computer Fashion Is Changing, Nice Work !!
Next: macro to expand into function body with declare at top