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
> (http://sbcl.sourceforge.net/platform-ta
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 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 ANSI/
-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 s
Don Dailey <[EMAIL PROTECTED]> writes:
> 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?
Oh, one additional comment: There are also implementations like ECL
(integration with plain C) and ABCL (integration with Jav
Don Dailey <[EMAIL PROTECTED]> writes:
> 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?
Huh, I don't have a really good overview, sorry. I only know, that the
performace characteristics of the different implementa
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 Swi
Maybe this link is a bit more interesting..
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=sbcl&lang2=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.
> http://shootout.alioth.d
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).
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 c
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 Teub
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 t
"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 tr
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 possibl
> 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 f
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/
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
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 a
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 compromise
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
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 expensive.
On Wed, Nov 21, 2007 at 09:29:42PM +, Stuart A. Yeates wrote:
> A C++ compiler can make those kinds of assumptions if the object is
> created within the current compilation unit and can not be overwritten
> from outside it. There are a whole class of optimizations in Java, C
> and C++ which can
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
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 performa
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
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. Th
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 others)
> > 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
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 i
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++
> 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.
N
> 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
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 projec
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
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 describ
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
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 pr
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 anythin
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 fo
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 us
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
> (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.
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
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 h
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 bo
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 highe
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
vi
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
>
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?
--
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 g
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
fun
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 yo
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
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 amou
54 matches
Mail list logo
