I think people that call java interpretted are somewhat misinformed. You
certianly can interpret it or any other language for that matter... but that
is not what is usually done. It is usually run through a JIT *compiler* so
that it is compiled. Interpretted is very different. I've written
Nick Apperson wrote:
But, to be fair, I totally agree that compiling python or ruby would give
you noticable speed gains. And as always, speed comparisons are only useful
in context. In terms of go programming if you are prototyping use
whatever the hell you want. If you are finishing
Hi Don,
Sorry if this idea has already been suggested and rejected, but would
it be possible to make the server automatically restart every night?
Joel
On Nov 21, 2007 1:41 PM, Don Dailey [EMAIL PROTECTED] wrote:
Jacques,
I am responsible for 9x9 CGOS and I was away for almost a week.
hahaha, good point... good point. Although I still will stick with C++, I
really ought to learn Lisp I think.
On Nov 22, 2007 2:43 AM, Raymond Wold [EMAIL PROTECTED] wrote:
Nick Apperson wrote:
But, to be fair, I totally agree that compiling python or ruby would give
you noticable speed
Nick Apperson [EMAIL PROTECTED] writes:
Java certainly supports both modes, but what I said is true. If you
are executing a loop repeatedly the actual code gets converted into
machine language that represents the actual code. It is not parsing
bytecodes anymore at this point.
It's a bit
On 21/11/2007, Stefan Nobis [EMAIL PROTECTED] wrote:
It's not an inherent feature of the
language that allows JIT.
That's not entirely true.
There are some languages (such as Perl) which have language features
which absolutely precludes JIT as we know it.
In Perl you can have a line of code
In theory, a perfect compiler given enough time would optimize all
languages to the same machine code if the program does the same thing.
actually, to be a bit nitpicky here, you can't do this. not even for
a single language.
s.
Stuart A. Yeates [EMAIL PROTECTED] writes:
There are some languages (such as Perl) which have language features
which absolutely precludes JIT as we know it.
Your example doesn't convince me: Your Perl example may be compiled
(but maybe the resulting code is a bit more complex than a direct
I think we are missing the point of programmer productivity with higher
level languages. High level languages MIGHT improve the speed at which
you write code, but usually that is a minor concern. In computer
GO, what you want is the pathway that gives you the best programs in the
least
Thanks for a great read there first of all.
But... and this is something I see time and again and I must admit I don't
really understand. What makes C faster than C++? I feel like C++ is all
about you don't pay for what you don't use. Furthermore, I feel that C++
has at least one feature that
On Wed, Nov 21, 2007 at 09:11:25AM +, Stuart A. Yeates wrote:
In Perl you can have a line of code that looks like:
@result = (dothis $foo, $bar);
which could be either of:
@result = (dothis($foo), $bar);
@result = dothis($foo, $bar);
And the correct choice can vary each time the
On Thu, Nov 22, 2007 at 11:36:58AM +1800, Nick Apperson wrote:
Thanks for a great read there first of all.
But... and this is something I see time and again and I must admit I don't
really understand. What makes C faster than C++? I feel like C++ is all
about you don't pay for what you
right... well C++ does have this using virtual methods. I meant to add that
part.
C++ also has templates which while they theoretically don't add any
performance. Practically speaking they add tons because you don't have to
split your optimization time between 10 or more versions of the same
On Wed, Nov 21, 2007 at 12:07:03PM -0500, Don Dailey wrote:
My advice when this question comes up (which language for go programmer)
is to first ask, what do you hope to achieve?If you want to build a
high performance go program, anything other than C or assembler is like
tying your hand
On Nov 21, 2007 1:41 PM, Don Dailey [EMAIL PROTECTED] wrote:
(gcc also supports -fprofile-generate and -fprofile-use, which is pretty
cool too - gcc will re-optimize the binary based on profiling
information gathered from a test run of the program. It can be quite a
non-trivial boost.)
Hi Nick,
When I say C, I really mean C or C++. C is basically a useful
subset of C++.
C++ may be closer to the ideal HP language than C.To me, the ideal
language will let you seamlessly step down to high performance coding in
something just as efficient as C but be able to use much
sure thing:
--
struct foo {
// some stuff gets executed
virtual void do_something(somestruct s); // base case executed by default
};
struct foo_foo : foo {
// some stuff gets executed
};
struct foo_bar : foo {
// some stuff gets executed
Hi Raymond,
The point I'm making is that you must focus on what's relevant.If
you are trying to win the title of world championship go program, then
maintainability of code is LOW on the list of what is important. In
a corporate environment it moves close to the TOP of the list of what is
(gcc also supports -fprofile-generate and -fprofile-use, which is pretty
cool too - gcc will re-optimize the binary based on profiling
information gathered from a test run of the program. It can be quite a
non-trivial boost.)
This puts even more distance between C/C++ and other languages. I
One thing that I haven't check into is whether the GDC D compiler has
these same options for profiling code and using the profile to further
improve the code. If it does, then the performance gap between C and D
may not increase.
- Don
Don Dailey wrote:
(gcc also supports -fprofile-generate
Don Dailey wrote:
For that, C currently appears to be the best choice.This in not
just my opinion, there is empirical evidence to support this claim.
The problem with empirical evidence is that you don't get the very
much needed all else being equal. The people that code in C (and get
On Thu, Nov 22, 2007 at 12:04:53PM +1800, Nick Apperson wrote:
right... well C++ does have this using virtual methods. I meant to add that
part.
I'm sorry, I still don't get this - what do virtual methods have to do
with branch prediction? Can you elaborate, please?
--
On Nov 21, 2007 1:18 PM, Petr Baudis [EMAIL PROTECTED] wrote:
On Thu, Nov 22, 2007 at 12:04:53PM +1800, Nick Apperson wrote:
right... well C++ does have this using virtual methods. I meant to add
that
part.
I'm sorry, I still don't get this - what do virtual methods have to do
with
Heikki,
Yes, I like your approach of a library and using high level language.
One must be careful that it doesn't get in the way. Sometimes, the low
level library imposes some constraints so that you still don't quite get
the best of both worlds.
For example it would be great if you could
I disagree with almost everything Donn wrote.
Thanks to Moore's law, it is somewhere between unusual and rare for
the execution speed penalty of the language to matter, and if it
matters today (some but not all languages are fast enough), it won't
matter when the program is finished.
Thought
Over the years I've had a dribble of requests for my collection
of scored games. The most recent request inspired me to stop
the water torture by just posting it for general use.
The collection contains 600 professional games with
an exact score, and machine-readable annotations for
which
On Wed, Nov 21, 2007 at 11:47:05AM -0800, Dave Dyer wrote:
I disagree with almost everything Donn wrote.
Thanks to Moore's law, it is somewhere between unusual and rare for
the execution speed penalty of the language to matter, and if it
matters today (some but not all languages are fast
On Wed, 2007-11-21 at 14:11 -0500, Don Dailey wrote:
Experience in a language is a factor, but nobody refutes that properly
coded C is fastest (next to properly code assembly) and if performance
is your goal, then anything else accepts some compromise. That
compromise may work well for a
On Wed, Nov 21, 2007 at 09:16:48PM +0100, Raymond Wold wrote:
On Wed, 2007-11-21 at 14:11 -0500, Don Dailey wrote:
Experience in a language is a factor, but nobody refutes that properly
coded C is fastest (next to properly code assembly) and if performance
is your goal, then anything else
On Nov 21, 2007 3:36 PM, Petr Baudis [EMAIL PROTECTED] wrote:
On Wed, Nov 21, 2007 at 09:16:48PM +0100, Raymond Wold wrote:
On Wed, 2007-11-21 at 14:11 -0500, Don Dailey wrote:
Experience in a language is a factor, but nobody refutes that properly
coded C is fastest (next to properly
A very minor nitpick: I notice that during the processing that you
appear to have removed all the RU properties[1], which are technically
mandatory and potentially useful.
These records were converted from other formats, and never had RU
properties.
Nick, do you know for a fact that a C++ complier will optimize for the
base case of a virtual function? I was under the impression that it
doesn't know (as in can't determine at compile time) whether the
function was overwritten or not so it doesn't favor any of the cases. In
fact I can't even
I think that's somewhat contrived as well. I don't have that good idea
about all the populat computer go algorithsm, do you have example of
reasonably performing algorithm with these properties?
A standard alpha-beta driven search takes exponentially more time
with search depth, so an
Don Dailey [EMAIL PROTECTED] writes:
To me, the ideal language will let you seamlessly step down to high
performance coding in something just as efficient as C but be able
to use much higher level language features without getting in the
way of performance
Hmmm... you are just describing
On 21/11/2007, Adrian Grajdeanu [EMAIL PROTECTED] wrote:
Nick, do you know for a fact that a C++ complier will optimize for the
base case of a virtual function? I was under the impression that it
doesn't know (as in can't determine at compile time) whether the
function was overwritten or not
Remi Munos wrote:
I have updated the BAST paper, providing additional comparison with UCT, as
suggested by one person in the list. See: https://hal.inria.fr/inria-00150207
after reading the paper, I have two questions:
How did you deal with unexplored nodes in Flat UCB and BAST in your
On Nov 21, 2007 10:22 PM, Stefan Nobis [EMAIL PROTECTED] wrote:
Hmmm... you are just describing Common Lisp. :)
Man, we really need a complete Common Lisp Go Framework which also has
some fast low-level code to show all these C gurus its true power :)
Maybe we should really think of a project
Some chess programmers have told me that this feature works much
better in Visual C++ than in gcc. It's too bad I am not willing to
program in Windows to verify it.
I have compiled GNU Go with both GCC and Visual C++ 2008. The binary of
Visual C++ was almost half the size of the GCC one, but 3
At 02:30 PM 11/21/2007, Chris Fant wrote:
I found the shape library to be interesting. I never knew about that
before. It appears to be very old (stable since 1987, ...the poor
unfortunates who don't have a graphical interface). I was wondering
if you had any plans to build on this work and
What's to say that a computer program can't code assembly better than
any human possibly could? There are a ton of tasks that computers do
thousands of times better than humans. I think it makes perfect sense
that code written in C can execute faster than human-written assembly
code.
No
On Nov 21, 2007 5:37 PM, Ben Lambrechts [EMAIL PROTECTED] wrote:
Some chess programmers have told me that this feature works much
better in Visual C++ than in gcc. It's too bad I am not willing to
program in Windows to verify it.
I have compiled GNU Go with both GCC and Visual C++ 2008.
On Nov 21, 2007 6:12 PM, [EMAIL PROTECTED] wrote:
What's to say that a computer program can't code assembly better than
any human possibly could? There are a ton of tasks that computers do
thousands of times better than humans. I think it makes perfect sense
that code written in C can
- Original Message
From: Dave Dyer [EMAIL PROTECTED]
The only methodology where both networking and GUIs are cross platform
is Java.
Not so - Microsoft's .NET framework has both networking and GUI support. The
Mono provides a Linux implementation. In fact, with Silverlight (and
Dave,
Thanks for sharing! I've been using this collection over the years for testing.
- Original Message
From: Dave Dyer [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Wednesday, November 21, 2007 11:54:35 AM
Subject: [computer-go] re: completed game scoring
Over
Arguments about the quality of compiler optimizations vs. hand coding
are pointless, because programmers optimize programs in ways that compilers
are (correctly) forbidden to do; by changing the algorithm.
For example, if I happen to know x will always be an integer
from 0 to 359, I can
Not so - Microsoft's .NET framework has both networking and GUI support. The
Mono provides a Linux implementation. In fact, with Silverlight (and
Moonlight, for Mono), the .NET framework can be used within a modern web
browser (very similar to Java and Flash combined).
It remains to be seen
Not so - Microsoft's .NET framework has both networking and GUI support. The
Mono provides a Linux implementation. In fact, with Silverlight (and
Moonlight, for Mono), the .NET framework can be used within a modern web
browser (very similar to Java and Flash combined).
It remains to be seen
Why should a super-sophisticated compiler with algebraic type
inference not be able to do this one day?
On Nov 22, 2007 12:36 AM, Dave Dyer [EMAIL PROTECTED] wrote:
Arguments about the quality of compiler optimizations vs. hand coding
are pointless, because programmers optimize programs in
No compiler will ever do *all* of the optimizations
that are possible, because most optimizations are
NP-complete or even much worse. For example the
equivalance of boolean expressions is NP-complete.
Some potential optimizations (such as replacement
of data structures) may not even
Because many optimizations take exponential or worse
time to figure out if they apply. This means that
the sun would explode before your compile would finish.
Yes, compilers will get more sophisticated over time.
No, they will not replace any algorithms or data structures.
Michael Wing
Why
Dave,
The only thing that is fast enough is some fixed algorithm that tends
to be boring.The whole reason for Moore's Law is that few people
think their computers are fast enough.They will NEVER be fast enough
and we will always want our computers to be faster because they clearly
can do
On Nov 21, 2007, at 12:16 PM, Raymond Wold wrote:
This assumes that to be cutting edge, cycles matter. If your
algorithms
are such that doubling the execution time available means a 0.01%
increase in wins (this is *obviously* not true for a Monte Carlo-heavy
program, but might be for
Raymond Wold wrote:
On Wed, 2007-11-21 at 14:11 -0500, Don Dailey wrote:
Experience in a language is a factor, but nobody refutes that properly
coded C is fastest (next to properly code assembly) and if performance
is your goal, then anything else accepts some compromise. That
Do you believe GO is not NP
hard or that there is some intrinsic reason that a properly programmed
computer would not benefit from more resources?
You missed my point completely. As a programmer with finite
resources, especially time, if I spend a year squeezing extra
performance out of a
Colin Kern wrote:
On Nov 21, 2007 3:36 PM, Petr Baudis [EMAIL PROTECTED] wrote:
On Wed, Nov 21, 2007 at 09:16:48PM +0100, Raymond Wold wrote:
On Wed, 2007-11-21 at 14:11 -0500, Don Dailey wrote:
Experience in a language is a factor, but nobody refutes that properly
coded
Arguments about the quality of compiler optimizations vs. hand coding
are pointless, because programmers optimize programs in ways that compilers
are (correctly) forbidden to do; by changing the algorithm.
For example, if I happen to know x will always be an integer
from 0 to 359, I can
On Nov 21, 2007, at 4:06 PM, Don Dailey wrote:
However, for me the coding time is very small even though the
development time is large. I spend more time thinking about the
program than coding it, and I spend a great deal of time waiting
on the
computer, because I have no clue what will
On Nov 21, 2007 7:24 PM, Don Dailey [EMAIL PROTECTED] wrote:
Raymond Wold wrote:
On Wed, 2007-11-21 at 14:11 -0500, Don Dailey wrote:
Experience in a language is a factor, but nobody refutes that properly
coded C is fastest (next to properly code assembly) and if performance
is your
Dave Dyer wrote:
I think that's somewhat contrived as well. I don't have that good idea
about all the populat computer go algorithsm, do you have example of
reasonably performing algorithm with these properties?
A standard alpha-beta driven search takes exponentially more time
with
A standard alpha-beta driven search takes exponentially more time
with search depth, so an exponential increase in speed results in
a very small incremental improvement in seeing'. Improvements
in the quality of the evaluation at anything less than exponential
cost more effective at
On Nov 21, 2007 7:06 PM, Don Dailey [EMAIL PROTECTED] wrote:
You see to have very old-fashioned ideas about the whole programming
philosophy.You take the view that a project like go is a fixed
static task and that you must optimize the programmers time in typing
in code. And then you
My mind is open on this. I'm not a lisp programmer but I have
considered learning it at some point and I'm sure I will.
- Don
Benjamin Teuber wrote:
On Nov 21, 2007 10:22 PM, Stefan Nobis [EMAIL PROTECTED] wrote:
Hmmm... you are just describing Common Lisp. :)
Man, we really
Dave Dyer wrote:
A standard alpha-beta driven search takes exponentially more time
with search depth, so an exponential increase in speed results in
a very small incremental improvement in seeing'. Improvements
in the quality of the evaluation at anything less than exponential
cost more
Don Dailey wrote:
Dave Dyer wrote:
A standard alpha-beta driven search takes exponentially more time
with search depth, so an exponential increase in speed results in
a very small incremental improvement in seeing'. Improvements
in the quality of the evaluation at anything less than
Not so - Microsoft's .NET framework has both networking and GUI support.
The Mono provides a Linux implementation. In fact, with Silverlight (and
Moonlight, for Mono), the .NET framework can be used within a modern web
browser (very similar to Java and Flash combined).
It remains to be
Actually, putting all the code in headers helps with function inlining more
than anything. The virtual function stuff is very complicated because
usually code can be linked in at runtime that adds new functionality (i.e. a
new derived class).
Make no mistake, virtual functions are VERY
A bird's-eye view of computer-Go programming: a large part of what a Go program
does will probably be some sort of analysis of a deep tree of possible moves,
involving the exploration of millions of possible positions. The guts of this
should be as optimal as possible. A slower language such as
I agree with you 100%. You embody the methodology behind C++. The only
problem I can see with adding something like that to C++ is that many times
the compiler can't determine at compile time if a value is violating the
contract. If the feature were added to C++, the programmer would have to be
68 matches
Mail list logo
