Robert said:
> I'll go out on a limb and say that offering object-level caching is
> the single biggest performance enhancement we make for the most
common
> cases.
A clarifying question. How did you ensure ACID properties in the DCM
scenario in the presence of threading? Without letting
On Fri, 2008-05-16 at 11:26 -0400, Ian Eslick wrote:
> Prevalence is much, much faster because you don't have to flush data
> structures on each commit, so cl-prevalence performance with
> Elephant's data and transaction abstractions would be a really nice
> design point. I wonder if we woul
Linus Nordberg <[EMAIL PROTECTED]> wrote
Fri, 16 May 2008 15:01:54 +0200:
| | Elephant is borked in SBCL 1.0.16 (due to its heavy UFFI magic lifting),
| | and it hasn't been fixed in the SBCL development repository yet, either.
|
| Thanks. 1.0.10 shows the same behaviour while 1.0.6 seem to do b
I should also say that the serializer has to be thread safe, so there
is some non-trivial time overhead in terms of locking on each
serializer call. I wish I could do primitive atomic ops or at least
something like a futex in common lisp, then I could create deadlock
free data structures a
I don't disagree with you that it's easy to create expensive/slow
programs. My only point was that when it matters, it doesn't
necessarily have to be a determinative issue.
The big overheads in Elephant are due to Lisp's data model and the use
of the MOP. The serializer is currently desig
IE> I doubt that using a Lisp with a modern compiler affects CPU time in
IE> any interesting way;
IE> I've observed that algorithm implementation with reasonable data
IE> structure choices is within 10's of % points of the same algorithm in
IE> C.
it's possible to optimize single function, but ty
Linus Nordberg <[EMAIL PROTECTED]> wrote
Fri, 16 May 2008 15:01:54 +0200:
| Thanks. 1.0.10 shows the same behaviour while 1.0.6 seem to do better
| wrt to SBCL and FFI:
I spoke too early. This was on SBCL 1.0.6 without threading support.
Building 1.0.6 with threading results in
The CC envir
> Anyone contacted the SBCL team on this?
This is an issue that has been well-known on sbcl-devel for
the last few weeks.
Leslie
___
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
I checked, Rucksack writes dirty objects to disk on each commit - so
should have the same performance profile as our existing backends, of
course with different constants...
Ian
On May 16, 2008, at 11:26 AM, Ian Eslick wrote:
I just wanted to clarify a few points in this interesting dis
I just wanted to clarify a few points in this interesting discussion.
but if we are using high-level language like Lisp, it's much more
likely that CPU overhead will be large comparing to memory latency.
and as compression, even simpiest/fastest one will only add to CPU
overhead, i'm very
Anyone contacted the SBCL team on this?
Bryan
On Friday 16 May 2008 04:19:07 am Leslie P. Polzer wrote:
>
> Elephant is borked in SBCL 1.0.16 (due to its heavy UFFI magic lifting),
> and it hasn't been fixed in the SBCL development repository yet, either.
>
> Use an earlier version of SBCL.
>
??>> or it will matter if people are doing lots of linear reads -- but it's
??>> hard for me to imagine such database access patterns.
RLR> I think linear reads are quite common. They are, after all, why we
RLR> have implemented range queries. Moreover, the act of reading all the
RLR> data into
> Thanks. 1.0.10 shows the same behaviour
Okay, this might or might not be the bug in .16 that I was referring
to then.
Leslie
___
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
"Leslie P. Polzer" <[EMAIL PROTECTED]> wrote
Fri, 16 May 2008 13:19:07 +0200 (CEST):
| Elephant is borked in SBCL 1.0.16 (due to its heavy UFFI magic lifting),
| and it hasn't been fixed in the SBCL development repository yet, either.
Thanks. 1.0.10 shows the same behaviour while 1.0.6 seem to d
Elephant is borked in SBCL 1.0.16 (due to its heavy UFFI magic lifting),
and it hasn't been fixed in the SBCL development repository yet, either.
Use an earlier version of SBCL.
Leslie
___
elephant-devel site list
elephant-devel@common-lisp.net
http
On Fri, May 16, 2008 at 12:50 AM, Glenn Tarcea <[EMAIL PROTECTED]> wrote:
>
> I had never looked at Rucksack before. The code is very well structured
> indeed!
>
> A couple of thoughts:
>
> 1. Could the Rucksack B-Tree code be separated out, abstracted a little and
> put in a separate project (eg,
Hi,
I'm trying to get Elephant running with SBCL-1.0.16 built with threading
support, FreeBSD-6.2 on amd64, db-4.5 from ports.
--8<---cut here---start->8---
* (asdf-install:install 'elephant)
[...]
; $ gcc -L/usr/local/lib/db45/ -I/usr/local/include/db45/ -shar
> I had never looked at Rucksack before. The code is very well
> structured indeed!
Yes, we're lucky.
> A couple of thoughts:
>
> 1. Could the Rucksack B-Tree code be separated out, abstracted a
> little and put in a separate project (eg, a cl-btree, or ldb for
> example)? This would allow othe
18 matches
Mail list logo
