From: Jozef Kosoru <zyzstar@uid0.sk>
To: Brian Hurt <bhurt@spnz.org>
Cc: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Array 4 MB size limit
Date: Sat, 20 May 2006 12:51:08 +0200 [thread overview]
Message-ID: <20060520105108.GC32550@osiris.uid0.sk> (raw)
In-Reply-To: <Pine.LNX.4.63.0605192035040.10710@localhost.localdomain>
On Fri, May 19, 2006 at 20:57:35 -0400, Brian Hurt wrote:
> >Yes. 32-bit x86 platform is not going away anytime soon. Given that
> >512M RAM is now standard and 1G RAM is very common for an average PC
>
> This is what boggles my imagination. The combination of obstinate
> adherence to a limited platform (x86-32) in the same breath as a
> recognition that we are approaching the limitations of that
> architecture. It's the 640K limit all over again.
>
> And no, segments will not help the situation. Every single process is
> limited to 4G of address space, period. Read the Intel CPU docs.
> With reasonable amounts of virtual memory we're well above that
> already- and we're approaching that with real memory.
4G address space limit is off-topic here. Please note that the OCaml
array size limit is 4M not 4G.
> Now, I realize the core reasons for the delay in moving to 64-bits are
> industry wide. Intel's Itanium fiasco delayed Intel introducing a
> 64-bit chip at least 7 years. And Microsoft seems to be incapable of
> releasing a new OS- 32-bit or 64-bit. But that, I think, is the core
> of the problem- Ocaml's array limit is just one of many symptoms.
>
> And that's my point- we should be looking to fix the underlying
> problem, not looking to patch the symptoms. Because often times
> patching the symptoms and not addressing the core problem simply makes
> the whole situation worse- the underlying problem simply shows up in
> new ways, and the fix for the specific symptom often causes new
> problems.
I disagree. Actually I think an opposite. A suggestion to move to 64-bit
is just patching the symptoms of the real problem - a design flaw in the
OCaml programming language. And this issue will not go away on 64-bits.
Just like 22 bits for the array size is a completely artificial limit on
32-bit platforms, (N - 10) imposes once again such an unlogical 54 bits
limit on 64-bit computers. And I don't think "it makes complete sense on
a 64-bit architecture".
If you create OCaml programs for yourself then maybe you can switch to
64-bits overnight (and perpahs you already did so). But if you need to
distribute your application to customers/users then it's much more
complicated. And explaining them that they should upgrade all
workstations because your software has various 4M limitations here and
there sounds like a bad joke, doesn't it?
32-bit x86 platform is still good enough for many purposes and its 2^32
limit is acceptable in most cases while 2^22 is not.
Jozef
--
jozef kosoru
http://zyzstar.kosoru.com
next prev parent reply other threads:[~2006-05-20 10:49 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-15 18:12 akalin
2006-05-15 18:22 ` [Caml-list] " Nicolas Cannasse
2006-05-15 20:32 ` Damien Doligez
2006-05-15 21:27 ` akalin
2006-05-15 22:51 ` Oliver Bandel
2006-05-16 0:48 ` Brian Hurt
2006-05-16 9:57 ` Damien Doligez
2006-05-16 15:10 ` Markus Mottl
2006-05-16 8:01 ` Xavier Leroy
2006-05-16 8:20 ` Nicolas Cannasse
2006-05-19 17:13 ` Xavier Leroy
2006-05-19 5:57 ` Frederick Akalin
2006-05-19 6:21 ` Oliver Bandel
2006-05-19 12:15 ` Jon Harrop
2006-05-19 19:36 ` akalin
2006-05-19 20:17 ` Oliver Bandel
2006-05-19 16:28 ` Jozef Kosoru
2006-05-19 20:08 ` Oliver Bandel
2006-05-19 21:26 ` Jon Harrop
2006-05-20 1:06 ` Brian Hurt
2006-05-20 18:32 ` brogoff
2006-05-20 21:29 ` immutable strings II ([Caml-list] Array 4 MB size limit) Oliver Bandel
2006-05-22 22:09 ` Aleksey Nogin
2006-05-20 21:11 ` immutable strings (Re: [Caml-list] " Oliver Bandel
2006-05-25 4:32 ` immutable strings (Re: " Stefan Monnier
2006-05-25 5:56 ` [Caml-list] " Martin Jambon
2006-05-25 7:23 ` j h woodyatt
2006-05-25 10:22 ` Jon Harrop
2006-05-25 19:28 ` Oliver Bandel
2006-05-25 11:14 ` Brian Hurt
2006-05-25 19:42 ` Oliver Bandel
2006-05-26 6:51 ` Alain Frisch
2006-05-25 17:31 ` Aleksey Nogin
2006-05-25 19:54 ` Martin Jambon
2006-05-25 11:18 ` Brian Hurt
2006-05-25 17:34 ` Aleksey Nogin
2006-05-25 18:44 ` Tom
2006-05-25 23:00 ` Jon Harrop
2006-05-25 23:15 ` Martin Jambon
2006-05-20 0:57 ` [Caml-list] Array 4 MB size limit Brian Hurt
2006-05-20 1:17 ` Frederick Akalin
2006-05-20 1:52 ` Brian Hurt
2006-05-20 9:08 ` Jozef Kosoru
2006-05-20 10:12 ` skaller
2006-05-20 11:06 ` Jozef Kosoru
2006-05-20 12:02 ` skaller
2006-05-20 21:42 ` Oliver Bandel
2006-05-21 1:24 ` skaller
2006-05-21 14:10 ` Oliver Bandel
[not found] ` <Pine.LNX.4.63.0605200847530.10710@localhost.localdomain>
2006-05-20 19:52 ` Jozef Kosoru
2006-05-20 21:45 ` Oliver Bandel
2006-05-21 9:26 ` Richard Jones
[not found] ` <5CE30707-5DCE-4A22-970E-A49C36F9C901@akalin.cx>
2006-05-22 10:40 ` Richard Jones
2006-05-20 10:51 ` Jozef Kosoru [this message]
2006-05-20 14:22 ` Brian Hurt
2006-05-20 18:41 ` j h woodyatt
2006-05-20 19:37 ` Jon Harrop
2006-05-20 20:47 ` Jozef Kosoru
2006-05-26 18:34 ` Ken Rose
2006-05-20 22:07 ` Oliver Bandel
2006-05-20 15:15 ` Don Syme
2006-05-20 22:15 ` Oliver Bandel
2006-05-21 1:25 ` skaller
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=20060520105108.GC32550@osiris.uid0.sk \
--to=zyzstar@uid0.sk \
--cc=bhurt@spnz.org \
--cc=caml-list@inria.fr \
/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