Thanks for the fast response
I did look at the source code for diffuse and yes I don't think I can optimize it very much unless I get to call a C++ routine (my native language) with a pointer to the patches array and linearize the inner loop (my world is 500x500 and I have lots of ram.) I have the model run on all 8 cores so going parallel might not be my solution if all else fails I will just have to run it in parallel on many networked computers. I downloaded the headless brunch and will try to see what can be done, if I have any success I will surely let you know (and give you credit in the final paper-:) Thanks again *Get your facts first*, and then you can distort them as much as you please. “Facts are stubborn, but statistics are more pliable.” Mark Twain Benjamin I. Czaczkes PhD Now in Oxford UK but also from The Hebrew University of Jerusalem, Programming Instruction Unit, Givat Ram, Jerusalem 91904, Israel Site: pl1.mscc.huji.ac.il Phone: 972-2-6586297 Fax: 972-2-6586246 On Monday, February 17, 2014 2:38:47 PM UTC, Seth Tisue wrote: > > >>>>> "Benjamin" == Benjamin Czaczkes <btm...@gmail.com <javascript:>> > writes: > > Benjamin> My model runs for 24 days :( > Benjamin> The main culprit is diffuse > > The code behind the `diffuse` and `diffuse4` primitives is very fast. > It's already been optimized heavily. I'd be somewhat surprised if you > can do better, but you're welcome to try! The code you're trying to > beat is here: > > > https://github.com/NetLogo/NetLogo/blob/5.0.x/src/main/org/nlogo/agent/Torus.java#L192 > > > Benjamin> I need something faster (direct access from java to _patches > Benjamin> maybe) Any Ideas? > > world.fastGetPatchAt() (used in the code linked above) is the fastest > available method for iterating over patches. At least, I don't have any > idea for what could be possibly be any faster; it's a single method > call, the body of which just does a direct array access. (The caller > is expected to do its own bounds checking.) > > Hmm, well, you might try to write parallel code that takes advantage of > more than one CPU core; that's one tack we haven't tried taking yet. > > Must your simulation really do diffusion so often? Maybe do it every 10 > ticks instead of every tick, something like that? > > -- > Seth Tisue | Northwestern University | http://tisue.net > developer, NetLogo: http://ccl.northwestern.edu/netlogo/ > -- You received this message because you are subscribed to the Google Groups "netlogo-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to netlogo-devel+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
