caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: David Sheets <kosmo.zb@gmail.com>
To: jon@ffconsultancy.com
Cc: "Richard W.M. Jones" <rich@annexia.org>,
	Gabriel Scherer <gabriel.scherer@gmail.com>,
	 Tom Ridge <tom.j.ridge+list@googlemail.com>,
	caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Question about garbage collection and impact on performance
Date: Sun, 22 Dec 2013 03:04:41 +0000	[thread overview]
Message-ID: <CAAWM5TxDBdRqY3jS9Vh09+HK0oQwQxLgchLofQ=_j8N+xYSdZA@mail.gmail.com> (raw)
In-Reply-To: <089e01cefebd$0e12f300$2a38d900$@ffconsultancy.com>

On Sun, Dec 22, 2013 at 2:25 AM, Jon Harrop <jon@ffconsultancy.com> wrote:
> Richard Jones wrote:
>> > My personal impression is that the question is not that well-posed:
>> > - if you assume infinite memory, you don't actually need a GC (and for
>> > any input you can tweak the GC setting to make sure no collection
>> > happens)
>>
>> How could "infinite" memory be implemented without affecting the runtime
> of programs on such a machine?
>
> I guess O(1) lookup would actually be O(n^(1/3)) due to that speed of light
> thing. ;-)

I think there are some fundamental limits to information density in
the local universe. I reply here, though, to propose that the lookup
would be O(n^(1/2)) because, locally, space is Euclidean. I'm not sure
how you got the 1/3 exponent.

This complexity analysis is a little weird, though, as some of your
infinite memory would be arbitrarily far away and thus would suffer
the square root of arbitrarily large latency. Also, your address space
is infinite? Of course, the machine words are infinitely sized.

It seems that even in theoretical computer science, arbitrarily large
memory must be modeled as a distributed system due to the laws of
physics.

Perhaps I've made an error in my understanding. Please forgive and
correct me, if so.

Happy upswing,

David

  reply	other threads:[~2013-12-22  3:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-04 12:20 Tom Ridge
2013-12-04 12:43 ` Malcolm Matalka
2013-12-04 13:48 ` Gabriel Scherer
2013-12-19 22:47   ` Richard W.M. Jones
2013-12-22  2:25     ` Jon Harrop
2013-12-22  3:04       ` David Sheets [this message]
2013-12-22 12:43         ` Jeff Schultz
2013-12-22 10:41       ` Richard W.M. Jones
2013-12-04 18:09 ` Jon Harrop
2013-12-05  1:09 ` Jacques Garrigue
2013-12-05 10:08   ` Tom Ridge
2013-12-05 10:37     ` Malcolm Matalka
2013-12-05 10:48     ` Michael Hicks
2013-12-05 11:21       ` Tom Ridge
2013-12-05 21:09       ` Jon Harrop

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAWM5TxDBdRqY3jS9Vh09+HK0oQwQxLgchLofQ=_j8N+xYSdZA@mail.gmail.com' \
    --to=kosmo.zb@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=gabriel.scherer@gmail.com \
    --cc=jon@ffconsultancy.com \
    --cc=rich@annexia.org \
    --cc=tom.j.ridge+list@googlemail.com \
    /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 NNTP newsgroup(s).