Isaac Gouy <[EMAIL PROTECTED]> writes:
> Again, you seem happy to say they are overrated and dismiss them
> without actually having looked - that is not "scientific"!
Yes, my critique is not up to the standards I measure the shootout
with. But my main point is: Performance has so many (sometimes
Isaac Gouy <[EMAIL PROTECTED]> writes:
> - are you thinking of specific methodological objections?
Yes, quite some methodological objections. To be fair: I'm no expert
in this field and I haven't looked on the site for quite some time.
But benchmarks are really hairy, it's really easy to measure
Darren Cook <[EMAIL PROTECTED]> writes:
> Stefan, judging by this site (which I posted some links from
> yesterday) your intuition is correct:
> http://shootout.alioth.debian.org/
To clarify: I don't really like these non-scientific benchmarks (in
many cases I assume no one or only really few p
Don Dailey <[EMAIL PROTECTED]> writes:
> I thinks it's very difficult to outperform C since C really is just
> about at the level of assembly language.
No, in special cases it's not that hard to outperform C, because the
language spec dictates some not so efficient details. C has an ABI and
it's
terry mcintyre <[EMAIL PROTECTED]> writes:
> Any of those with recent Lisp experience have any opinions about
> multicore capabilities?
Multithreading is not available in ANSI CL, but most implementations
support multithreading in some ways. AFAIK SBCL, Corman Lisp, OpenMCL
and some more have tru
Dave Dyer <[EMAIL PROTECTED]> writes:
> The biggest underlying reason is the multiple constraints on
> memory management;
But these constraints are not absolute truths. At least not in Common
Lisp: The language spec is not as constrained as described here and
the compilers add some additional fr
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
Dave Dyer <[EMAIL PROTECTED]> writes:
> Languages like SQL and Prolog don't specify algorithms, they
> describe the desired result.
Take a look as Haskell -- it's a very high level language but
functional, so you are describing algorithms in it. Yet the compiler
has so much knowledge (because of
"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
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
"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 dire
"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
"Nick Apperson" <[EMAIL PROTECTED]> writes:
> Java and C# are both compiled at some point if the same loop is
At some point everything has to be translated to machine code. But
Java, C#, Ruby etc. are doing this at execution time -- that what most
people call a interpreter.
You are right, the in
"Colin Kern" <[EMAIL PROTECTED]> writes:
> I think the reason for Ruby being so much slower is because it is an
> interpreted language rather than a compiled language.
It's not the main problem (interpreted languages are slower than those
compiled to native code, but than even Java and C# are int
[EMAIL PROTECTED] (William Harold Newman) writes:
> Still, though, sometimes useful things resist elegant implementation
> in CL. For example:
> * I doubt CL can be customized to support a thread library nearly
> as gracefully as languages designed around threading from the
> ground up.
Don Dailey <[EMAIL PROTECTED]> writes:
> I must be a dinosaur - at least a minimalist - but I don't
> understand the big deal about library support that has been
> mentioned a lot here.
For Go library support isn't very important -- just one argument more
in favor of more exotic languages, that m
"Nick Apperson" <[EMAIL PROTECTED]> writes:
> And I don't htink I missed the point about productivity. I've heard
> that argument time and again. That is fine. I personally find that
> with the STL in C++ and with the ability to write my own templates,
> I can write algorithms in fewer lines of
"Álvaro Begué" <[EMAIL PROTECTED]> writes:
> If you learn how to use the STL containers in C++ and perhaps shared
> pointers from boost, you don't need GC and I doubt anything can give
> you much higher productivity.
I know the STL quite well and used Boost libraries since some of the
first beta
"Nick Apperson" <[EMAIL PROTECTED]> writes:
> Reference counting and copy on write.
Do you know that there's much more to garbage collection than
reference counting and that reference counting has some major
drawbacks? There are even hard real time capable garbage collectors
out there.
> But I'l
"Chris Fant" <[EMAIL PROTECTED]> writes:
> I would like some language recommendations.
So I would suggest Common Lisp: The programmable programming
language. I think it's the single most flexible language -- you get
everything, from imperative over object-oriented to functional and
declarative pa
"Bob Myers" <[EMAIL PROTECTED]> writes:
> Many of those complaining about XML don't seem to really know too
> much about it.
The problem with XML is, that most people using it don't know anything
about it and possible alternatives, using XML for everything, even
when there are better alternatives
"Robin Kramer" <[EMAIL PROTECTED]> writes:
> So if there was any language which allows a programmer to port their
> code to be compileable and executable on a wide variety of systems
> it is C.
Hey, are C and Java are all you guys know about?
What about Ada? I'd say it's much easier to write por
Dmitry Kamenetsky <[EMAIL PROTECTED]> writes:
> The forums that I really like are the TopCoder forums
> (http://forums.topcoder.com/). I like them for these reasons:
And really everything of these reason are features of good E-Mail
clients (except the +/- voting). So with the right client you get
Antoine de Maricourt <[EMAIL PROTECTED]> writes:
> I can develop very quickly 'quick and dirty' code to test new ideas
> in C++, and recode it in a very clean / organized / modular / robust
> ... code later if needed. This ability is not coming from the
> programming langage itself...
I beg to di
25 matches
Mail list logo
