> Marshall, we are indeed proposing extensions to MASON for selected JVM-based languages as part of an NSF proposal which is still pending. I'm interested in what your performance results are (command line only, no GUI) compared to the raw Java version. You might also try tutorial 1 and compare it to the Scheme version (in sim/app/scheme) and the Java version.
Great. Thanks Sean. At this point, I'm not trying for speed. I did things in my Clojure code that I'm pretty sure weren't going to make things as fast as possible, but which made the code clearer, for example. I was happy to get it to work, and didn't worry about performance. My Clojure version of the students app is indeed a lot slower than the Java version, it appears.
Is this what you want to see?:
Clojure:
java -cp ../../resources/mason.18.jar:../students-0.1.0-SNAPSHOT-standalone.jar:. students/Students -time 1000
MASON Version 18. For further options, try adding ' -help' at end.
Job: 0 Seed: 749994633
Job 0: Steps: 999 Time: 998 Rate: 92.47431
Job 0: Steps: 1998 Time: 1997 Rate: 112.20937
Job 0: Steps: 2997 Time: 2996 Rate: 113.32955
Job 0: Steps: 3996 Time: 3995 Rate: 113.34241
Job 0: Steps: 4995 Time: 4994 Rate: 113.35527
Job 0: Steps: 5994 Time: 5993 Rate: 112.79214
Java:
java -cp ../../resources/mason.18.jar:. students/Students -time 1000
MASON Version 18. For further options, try adding ' -help' at end.
Job: 0 Seed: 750056150
Job 0: Steps: 999 Time: 998 Rate: 2,307.15935
Job 0: Steps: 1998 Time: 1997 Rate: 13,684.93151
Job 0: Steps: 2997 Time: 2996 Rate: 18,163.63636
Job 0: Steps: 3996 Time: 3995 Rate: 17,839.28571
Job 0: Steps: 4995 Time: 4994 Rate: 19,588.23529
Job 0: Steps: 5994 Time: 5993 Rate: 18,500
I understand why you're concerned with speed--that's entirely appropriate given MASON's goals. For me, it might not be the same kind of worry. My comparison frameworks are NetLogo on one hand, and a special purpose, no-graphics ABM (pocpo2) that I wrote in Clojure. (Popco2 is generally fast enough for me--an order of magnitude better than an earlier version). I want to use MASON to write small ABMs--the kind of thing I'd write in NetLogo, and maybe to add some graphics to popco2. I suspect that MASON in Clojure will still be faster than NetLogo, at least once I figure out how to best use it in Clojure, but if not, I can worry about optimizations. Leaving some parts in Java is one option.
> STEP 1. Port some examples to the language in a very "Java" like programming style, and see what needs to be done to make it efficient. Here the objective is to verify that it is *possible* to target MASON from the language.
I guess I have started this, apart from the efficiency part.
> Our past experience has been that Clojure has some performance problems because we have to ref everything to get around the fact that multiagent simulation is very highly mutable. It's not Clojure's strong point.
I'll be exploring what can be done functionally behind the imperative style of MASON. I do think that imperative programming is natural for ABM, but I don't feel it's always required. My popco2 is entirely functional apart from output, although there's imperative code behind the scenes within some functions.
Marshall
>
> Marshall, we are indeed proposing extensions to MASON for selected JVM-based languages as part of an NSF proposal which is still pending. I'm interested in what your performance results are (command line only, no GUI) compared to the raw Java version. You might also try tutorial 1 and compare it to the Scheme version (in sim/app/scheme) and the Java version.
>
> Our past experience has been that Clojure has some performance problems because we have to ref everything to get around the fact that multiagent simulation is very highly mutable. It's not Clojure's strong point. So whereas optimized Kawa scheme can run tutorial 1 and flockers at something like 80% the speed of optimized Java, this isn't the case for Clojure, which is much (or *was* much) slower.
>
> If you're getting better results, I'd really like to hear how it's going, as I'd love to see a Clojure API for MASON. I'm cc:ing Michael Schader, who did the most recent Clojure attempt a few years back. Kawa may be hard to beat speadwise.
>
> In general the plan for external languages is as follows:
>
> STEP 1. Port some examples to the language in a very "Java" like programming style, and see what needs to be done to make it efficient. Here the objective is to verify that it is *possible* to target MASON from the language.
>
> STEP 2. Develop a set of wrapper functions in the language, or in MASON proper, to make many common tasks faster and more apropos to the langauge in question. For example in Kawa we might use macros and Kawa objects to produce an API for making and using agents and automatically scheduling them. Here the objective is to make an environment that is *useful* to typical people who use this language.
>
> Sean
>
>
> On May 6, 2015, at 10:24 PM, Marshall Abrams <[log in to unmask]> wrote:
>
>> I haven't used MASON in the past, I wanted to try using it with Clojure. I've been working through the tutorial in the manual, translating the Java into Clojure. Nearly everything up through section 2.8 is done. I'll probably be adding material from the rest of the chapter when I get a chance. In case you come across someone who's interested, the results are here:
>>
>> https://github.com/mars0i/majure
>>
>> A couple of days ago I came across the 2013 report planning future developments for MASON, and saw that there's a plan to develop Clojure interfaces. Has any work been done on that yet?
>>
>> Thanks to everyone who has worked on the development of MASON-
>>
>> Marshall
>>
>>
>> Marshall Abrams, Associate Professor
>> Department of Philosophy, University of Alabama at Birmingham
>> http://http://members.logical.net/~marshall
>> Email: [log in to unmask]; Phone: (205) 996-7483; Fax: (205) 975-6610
>> Mail: HB 414A, 900 13th Street South, Birmingham, AL 35294-1260; Office: HB 418
>>
>>
>
> ------------------------------
>
> End of MASON-INTEREST-L Digest - 18 Apr 2015 to 6 May 2015 (#2015-19)
> *********************************************************************
>
>
|
