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?

 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/

Reply via email to