-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 22, 2007, at 1:17 PM, Stefan Nobis wrote:
Benjamin Teuber [EMAIL PROTECTED] writes:
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 :)
I think so,
On Nov 25, 2007, at 10:29 AM, Ian Osgood wrote:
Folks might be interested in the Common Lisp chess program
Symbolic by Steven J. Edwards (of PGN fame). From his ICC
description:
Symbolic is a C++/Lisp chessplaying program written by S. J.
Edwards. Symbolic's C++ source is fully
On Nov 25, 2007, at 10:52 AM, Ian Osgood wrote:
On Nov 25, 2007, at 10:29 AM, Ian Osgood wrote:
Folks might be interested in the Common Lisp chess program
Symbolic by Steven J. Edwards (of PGN fame). From his ICC
description:
Symbolic is a C++/Lisp chessplaying program written by S.
On Fri, Nov 23, 2007 at 12:30:01AM +0100, Benjamin Teuber wrote:
AFAIK, CMUCL is the fastest free lisp available. But I would rather
stick with its offspring, SBCL, which might be a bit slower, but it is
being worked on actively, it is quite portable
Don Dailey 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 goal, then anything else accepts some
Raymond Wold wrote:
Do you have anything to back this up? I was under the impression that
most decent assembly programmers agreed that they can't compete with the
best C compilers.
Absolutely NOT.
Only the typical, perhaps 99.9% of the programs, made of: transfers,
conditionals, integer
Jacques Basaldúa wrote:
Of course, what is cool is very subjective debate: Some people
find it cool to depend on runtimes that increase at mega/month rate,
do what the API already does only much worse, gift the user with the
gray rectangle experience even on a quad-core. After two seconds of
Full agreement - I'll write more later when I find the time :)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
As far as I can tell, the optimizations that a compiler can't do are
higher-level optimizations that can be done in C and wouldn't require
the programmer to write assembly, or am I wrong about this?
just take a look at the generated assembly sometime and you'll
see things that you can make
terry mcintyre wrote:
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.
C is the one true language and must be indented with the one true brace
style :-)
- Don
Stefan Nobis wrote:
Benjamin Teuber [EMAIL PROTECTED] writes:
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
Benjamin Teuber [EMAIL PROTECTED] writes:
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 :)
I think so, too. :)
I don't want to say CL is the one and only language (for me surely it
is), I only try to
Stefan,
What is the state of common lisp these days?What is fastest compiler
for X86 and how does it compare to C code in performance?
I was either going to experiment with Forth or lisp in the near
future. I will get around to both eventually.
- Don
Stefan Nobis wrote:
Benjamin
I'm also curious about scheme compilers and the quality of code they
generate. Does anyone have the dirt on these?
- Don
Stefan Nobis wrote:
Benjamin Teuber [EMAIL PROTECTED] writes:
Man, we really need a complete Common Lisp Go Framework which also
has some fast low-level code to
AFAIK, CMUCL is the fastest free lisp available. But I would rather
stick with its offspring, SBCL, which might be a bit slower, but it is
being worked on actively, it is quite portable
(http://sbcl.sourceforge.net/platform-table.html) and it supports
native threads (CMUCL just has green threads).
Maybe this link is a bit more interesting..
http://shootout.alioth.debian.org/gp4/benchmark.php?test=alllang=sbcllang2=gcc
On Nov 23, 2007 12:30 AM, Benjamin Teuber [EMAIL PROTECTED] wrote:
Of course it's not easy
to compare speed of different languages, but e.g.
On Nov 22, 2007 12:13 PM, Jacques Basaldúa [EMAIL PROTECTED] wrote:
I am still waiting to
meet the first person who answers affirmatively to the question:
Have you ever paid for a program written in Java?
*raises hand*
You need wait no longer ^.^ - and that was back in the days when Swing
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 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
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
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
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
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
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
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
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
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
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
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
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
50 matches
Mail list logo
