From: Linas Vepstas <linasvepstas@gmail.com>
To: Marko Rauhamaa <marko@pacujo.net>
Cc: "guile-user@gnu.org" <guile-user@gnu.org>
Subject: Re: out-of-control GC
Date: Thu, 14 Sep 2017 13:31:59 -0500 [thread overview]
Message-ID: <CAHrUA36hWOmynS5X38U+mkgH1NucaCYgNi=rxJcKeujKXzbjjw@mail.gmail.com> (raw)
In-Reply-To: <877ex6qivt.fsf@elektro.pacujo.net>
Hi Marko,
A casual reply, then ...
On Sun, Sep 10, 2017 at 5:38 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Linas Vepstas <linasvepstas@gmail.com>:
>
> > On Sun, Sep 10, 2017 at 3:36 PM, Marko Rauhamaa <marko@pacujo.net>
> wrote:
> >
>
> Not everything in the world is done for performance. The #1 purpose for
> a programming language is managing complexity. Relatively few
> computation tasks require excellent performance, and there are other
> programming languages for that: C, C++, Java, C#, go
>
I agree in principle; the guts of my system are in C++, the casual
computations that string together the pipeline are in guile.
There are some 50+ dialects of scheme, and somewhere on the net is a giant
page of benchmarks comparing them. Guile ranks about 10th or 11th in that
list, which isn't bad, except that many of the #1 and #2 spots are
something like 10x faster. I'd like to see guile improve in those
rankings.
>
> Note that Java, C# and go are performant despite GC.
Well, some decades ago, there were a couple of PhD's down the hall from me,
and they were full-time assigned to improving java GC performance. That's
all they did, for years. And this was a long time ago. If java wasn't good
at this by now, there'd be ... it would be incomprehensible.
> The biggest
> performance drain for high-level programming languages such as Scheme or
> Python is the absence of compile-time typing. In fact, Python is adding
> optional static type annotation (which I'm afraid might be a big
> mistake).
>
Well that's a can of worms. Aside from static typing to benefit the
compiler, there's static typing to help the programmer understand what the
heck is being passed as an argument to some poorly documented, overly-long
function. This has always been a kind-of bugaboo of reading other people's
scheme code -- its too often too hard to understand.
This is also why python is popular: any shmo feels they can code in it; its
the new visual-basic of the 21st century, with all of the culture and
code-quality that implies.
One "obvious" solution to adding types in scheme is to go to caml/haskell,
but this does not obviously improve readability. (although types are
effing fantastic from the math/theoretical side: my system makes very very
heavy use of types and type constructors, But its unrelated to scheme)
For a certain class of problems, coding in python simply doesn't work:
graph data structures are naturally recursive and functional; they're a
natural fit for scheme, and are hard/painful/nearly impossible to
manipulate in python.
>
> You aren't thrashing by any chance...?
>
No.
>
>
> I believe that decision is left for GC_malloc(1L):
>
OK thanks
--linas
--
*"The problem is not that artificial intelligence will get too smart and
take over the world," computer scientist Pedro Domingos writes, "the
problem is that it's too stupid and already has." *
next prev parent reply other threads:[~2017-09-14 18:31 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-09 19:47 out-of-control GC Linas Vepstas
2017-09-10 4:14 ` Linas Vepstas
2017-09-10 16:50 ` Arne Babenhauserheide
2017-09-10 18:03 ` David Kastrup
2017-09-10 20:23 ` Linas Vepstas
2017-09-10 20:36 ` Marko Rauhamaa
2017-09-10 21:47 ` Linas Vepstas
2017-09-10 22:38 ` Marko Rauhamaa
2017-09-11 16:17 ` Arne Babenhauserheide
2017-09-14 18:31 ` Linas Vepstas [this message]
2017-09-14 18:58 ` Marko Rauhamaa
2017-09-14 20:15 ` Linas Vepstas
2017-09-14 20:36 ` David Kastrup
2017-09-14 20:45 ` Arne Babenhauserheide
2017-09-11 8:22 ` tomas
2017-09-14 20:19 ` Linas Vepstas
2017-09-13 17:13 ` David Kastrup
2017-09-10 22:17 ` Arne Babenhauserheide
2017-09-10 22:36 ` Arne Babenhauserheide
2017-09-14 7:44 ` Mark H Weaver
2017-09-10 16:53 ` Arne Babenhauserheide
2017-09-13 2:24 ` Mark H Weaver
2017-09-13 19:38 ` Arne Babenhauserheide
2017-09-13 19:57 ` David Kastrup
2017-09-13 20:37 ` Arne Babenhauserheide
2017-09-14 19:14 ` Linas Vepstas
2017-09-11 18:13 ` Hans Åberg
-- strict thread matches above, loose matches on Subject: below --
2017-09-11 7:42 Kjetil Matheussen
2017-09-14 18:41 ` Linas Vepstas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHrUA36hWOmynS5X38U+mkgH1NucaCYgNi=rxJcKeujKXzbjjw@mail.gmail.com' \
--to=linasvepstas@gmail.com \
--cc=guile-user@gnu.org \
--cc=marko@pacujo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).