Prev: Will and Abe's "Guide to Pyjamas"
Next: setprocname
From: Raymond Toy on 14 Jun 2010 15:34
On 6/14/10 1:53 PM, fortunatus wrote:
> For crying out loud, the best any compiler can do is make optimal
> machine language. Many C compilers can do that over most inputs. So

Is that why I had to use assembly code instead of C for some parts of my
previous projects?

There was even one example where the C compiler made spectacularly bad
code. I only needed 6 pointer registers (the arch has 8), but the
compiler decided to use only one or two and spilled and reloaded them
from the stack for each use. Yay!

Ray
From: Aaron W. Hsu on 14 Jun 2010 20:12
fortunatus wrote:

> The only point to discuss would be that Scheme - in the R5 version of
> the spec at least - doesn't have standard way to specify type data
> unless I am mistaken. Therefore you will find that Scheme compilers
> add their own syntax for it. Again we are led to a moot point.

One of the points of something like Chez Scheme is that it compiles
standard Scheme, without additional static typing -- which, personally,
I find rather annoying -- into code that is often quite competitive with
C code if not faster.

More specifically, there is nothing inherently slow about the Scheme
language. While there are some things that are inherently expensive,
they are not more expensive than the equivalent constructs in C by
nature. Scheme can be compiled into very fast code, without resorting to
tricks like type declarations, and there are real life compilers out
there which do this.

I've heard it said, it is easy to beat C compilers for fast code, it's
just hard to beat them at benchmarks written for C. That is, do the same
type of things as what Scheme gives you, such as lots of dynamic
allocation and resizing, higher order functions, and closures, and you
won't find C faster. Benchmarks to compare C with Scheme often don't
compare the things Scheme is good at, but focus only on the static
things that C was designed for.

Aaron W. Hsu
From: Grant Edwards on 14 Jun 2010 23:10
On 2010-06-15, Aaron W. Hsu <arcfide(a)sacrideo.us> wrote:

> I've heard it said, it is easy to beat C compilers for fast code, it's
> just hard to beat them at benchmarks written for C. That is, do the same
> type of things as what Scheme gives you, such as lots of dynamic
> allocation and resizing, higher order functions, and closures, and you
> won't find C faster.

I don't know about that...

It's hard to beat the speed of a program that segfaults immediately. ;)

It's hardly fair if you're going to demand that the C program actually
works correctly.

--
Grant


From: fortunatus on 16 Jun 2010 15:14
On Jun 14, 3:34 pm, Raymond Toy <toy.raym...(a)gmail.com> wrote:
> There was even one example where the C compiler made spectacularly bad
> code.  I only needed 6 pointer registers (the arch has 8), but the
> compiler decided to use only one or two and spilled and reloaded them
> from the stack for each use.  Yay!

That's one of the worst compiler stories I've heard since 1979! How
awful!
First  |  Prev  | 
Pages: 1 2
Prev: Will and Abe's "Guide to Pyjamas"
Next: setprocname