2009/8/14 terry mcintyre <terrymcint...@yahoo.com> > Peter Drake, I know Orego was written in Java. How do you handle memory > allocation? Is there an equivalent of the C method of pre-allocating a large > chunk and managing the nodes internally, instead of billions of alloc/free > cycles? >
I think the issue is that you want something that is flat - like a an array of structs in C that have no pointers in them (except perhaps to other nodes like them.) In Java, everything more than simple uboxed types are going to be objects that are much bigger than the sum of the useable pieces in them because java has all this infrastrure necssary for keeping track of them and where they are in memory and so on. At least I think it works that way. - Don > > > Terry McIntyre <terrymcint...@yahoo.com> > > “We hang the petty thieves and appoint the great ones to public office.” -- > Aesop > > ------------------------------ > *From:* Don Dailey <dailey....@gmail.com> > *To:* computer-go <computer-go@computer-go.org> > *Sent:* Friday, August 14, 2009 2:25:06 PM > > *Subject:* Re: [computer-go] Erlang and computer go > > I don't think JVM performance will be an issue for this. I assumed that > you were willing to sacrifice a small amount of speed for a high level > prototyping language and I think you will only get about 20-30% slowdown > over C - I'm judging this by the performance of the reference bots I did in > both java and C. > > You are probably not going to get any closer than this with any other high > level language. > > If you like lispy languages there is something called "bitc" which is > supposed to be pretty close to C in speed and there is also D, which has the > potential to be faster than C - although it isn't right now. D would > probably be a little closer to C speed than Java or Scala. > > My issue with Java and JVM is the memory hog nature and pathetic startup > times - which make it FEEL slow and unresponsive, but in actuality it is > pretty fast. I have found that java doesn't play well with memory - I > would not use Java (or Scala) if you plan to do the big memory thing with > MCTS, which likes efficient memory management and lots of space for nodes. > > > But I cannot say for sure that this won't work. I don't understand Java > enough and maybe there are data structures that you can preallocate in > unboxed fashion that will be efficient. But my sense of things is that a > node is going to be pretty fat. > > Honestly, I think your decision to stay with C is likely to be best. I > don't even consider anything else when I look at a project that I think is > going to need serious performance and memory requirements. > > - Don > > > > > On Fri, Aug 14, 2009 at 5:07 PM, Carter Cheng <carter_ch...@yahoo.com>wrote: > >> Thanks both I guess I will stick with C/C++ for now. I have looked at >> Scala before though not in this particular context. It looks like a pretty >> compelling language with some pretty nice features (true lambda functions, >> "argument" pattern matching among others). JVM performance does concern me >> however. >> >> I do have a followup question but I will make a separate topic of it. >> >> --- On Fri, 8/14/09, Vlad Dumitrescu <vladd...@gmail.com> wrote: >> >> > From: Vlad Dumitrescu <vladd...@gmail.com> >> > Subject: Re: [computer-go] Erlang and computer go >> > To: "computer-go" <computer-go@computer-go.org> >> > Date: Friday, August 14, 2009, 1:56 PM >> > On Fri, Aug 14, 2009 at 22:16, Carter >> > Cheng<carter_ch...@yahoo.com> >> > wrote: >> > > I have been considering experimenting with Erlang as a >> > means of prototyping certain aspects of a computer go >> > program and I was curious if anyone has tried this already. >> > How does a system like Erlang compare performance wise to >> > writing something in say C/C++ (fastest) or Java? >> > >> > Hi, >> > >> > I have started for some year ago to try to withe an Erlang >> > library to >> > play go, but got distracted by other stuff. >> > >> > Erlang has a lot of nice features, but in this particular >> > instance >> > speed isn't one of them. The main issue is that there are >> > no mutable >> > data structures, so for all processing there will be a lot >> > of copying. >> > This is somewhat simplified, of course, but the conclusion >> > still >> > holds. I don't have any hard numbers, it would depend very >> > much upon >> > the choice of data structure. >> > >> > Erlang would be good at coordinating work done by simple >> > and fast >> > slaves, written in C for example. It would be very >> > appropriate for a >> > distributed engine. The problem here is that the problem >> > of >> > synchronizing a distributed UCT tree hasn't been solvet >> > yet, to my >> > knowledge. >> > >> > regards, >> > Vlad >> > _______________________________________________ >> > computer-go mailing list >> > computer-go@computer-go.org >> > http://www.computer-go.org/mailman/listinfo/computer-go/ >> > >> >> >> >> _______________________________________________ >> computer-go mailing list >> computer-go@computer-go.org >> http://www.computer-go.org/mailman/listinfo/computer-go/ >> > > > > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ >
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
