Elephant experiences?
in [Lisp]
|
Prev: Amazing Video on How Computer Fashion Is Changing, Nice Work !!
Next: macro to expand into function body with declare at top
From: Captain Obvious on 6 Mar 2010 13:03 v> You must be right. No matter how hard I try, I cannot provoke an v> integrity error when the tuple is "small." When the tuple is "large," v> I get write errors about .1% of the time. Are you testing this on a single-core system? Race conditions are rare on them, but on SMP systems (multi-core and/or multi-processor) they are much more frequent. For this reason I usually pin Lisp processes to CPUs in production.
From: vanekl on 6 Mar 2010 13:53 On Mar 6, 1:03 pm, "Captain Obvious" <udode...(a)users.sourceforge.net> wrote: > v> You must be right. No matter how hard I try, I cannot provoke an > v> integrity error when the tuple is "small." When the tuple is "large," > v> I get write errors about .1% of the time. > > Are you testing this on a single-core system? > Race conditions are rare on them, but on SMP systems (multi-core and/or > multi-processor) they are much more frequent. > > For this reason I usually pin Lisp processes to CPUs in production. Captain, I'm running a Pentium 4 3.0GHz bx80532pg3000dsl6wk with hyperthreading. [Windows thinks it's dual-core.] Linux gnulou 2.6.25.20-co-0.8.0 #3 PREEMPT Sun Nov 8 15:44:29 CET 2009 i686 GNU/Linux I know I can get race conditions because I can invoke one in under a second under the right conditions. I've been running tests all morning. When the appended form is less than (length (prin1-to-string list)) < 4080 I don't get errors. When I don't hold to this size constraint I get malformed forms about . 1% of the time when all threads are trying to access the same file. It doesn't matter what the size of the file is. All that matters is 1) append mode, 2) no file deletions, 3) forms less than 4080 bytes. Nope, I take that back. I just got my first error. Well, it was an interesting experiment.
From: Captain Obvious on 6 Mar 2010 16:49 v> I'm running a Pentium 4 3.0GHz bx80532pg3000dsl6wk with v> hyperthreading. [Windows thinks it's dual-core.] Yep, hyperthreading is enough to qualify as dual-core in this case. v> Linux gnulou 2.6.25.20-co-0.8.0 #3 PREEMPT Sun Nov 8 15:44:29 CET 2009 v> i686 GNU/Linux But I don't see SMP in your uname, so linux can use only one core? v> When I don't hold to this size constraint I get malformed forms about . v> 1% of the time when all threads are trying to access the same file. I wonder if percentage will change if you use SMP kernel.
From: vanekl on 6 Mar 2010 17:29 "Captain Obvious" <udodenko(a)users.sourceforge.net> wrote in message news:4b92cddd$0$283$14726298(a)news.sunsite.dk... > v> I'm running a Pentium 4 3.0GHz bx80532pg3000dsl6wk with > v> hyperthreading. [Windows thinks it's dual-core.] > > Yep, hyperthreading is enough to qualify as dual-core in this case. > > v> Linux gnulou 2.6.25.20-co-0.8.0 #3 PREEMPT Sun Nov 8 15:44:29 CET 2009 > v> i686 GNU/Linux > > But I don't see SMP in your uname, so linux can use only one core? I run a funky kernel (CoLinux) that runs as a process hosted by WinXP. I just noticed that only one core is being used when I run the tests.
From: fortunatus on 8 Mar 2010 09:55
On Mar 6, 1:03 pm, "Captain Obvious" <udode...(a)users.sourceforge.net> wrote: > Are you testing this on a single-core system? > Race conditions are rare on them, but on SMP systems (multi-core and/or > multi-processor) they are much more frequent. > > For this reason I usually pin Lisp processes to CPUs in production. How do you pin Lisp threads to CPUs? Can you give an example for a particular Lisp implemtation (I'm hoping SBCL or CLISP...) or point a manual page? I assume by "Lisp processes" you are referring to threads in one Lisp image, rather than running multiple Lisp images? |