From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 2C699BB84 for ; Sun, 21 May 2006 00:07:03 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k4KM72KG008229 for ; Sun, 21 May 2006 00:07:02 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA14395 for ; Sun, 21 May 2006 00:07:01 +0200 (MET DST) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k4KM70hU008226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 21 May 2006 00:07:01 +0200 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from first.in-berlin.de (e178011229.adsl.alicedsl.de [85.178.11.229]) (authenticated bits=0) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id k4KM6wnu020029 for ; Sun, 21 May 2006 00:06:58 +0200 Received: by first.in-berlin.de (Postfix, from userid 501) id 0766B2881CA; Sun, 21 May 2006 00:07:02 +0200 (CEST) Date: Sun, 21 May 2006 00:07:02 +0200 From: Oliver Bandel To: caml-list@inria.fr Subject: Re: [Caml-list] Array 4 MB size limit Message-ID: <20060520220702.GF2670@first.in-berlin.de> References: <20060515141230.ajyupn2z28k0484s@horde.akalin.cx> <446986DF.1070308@inria.fr> <446D5E4A.8060005@akalin.cx> <20060519162844.GA32550@osiris.uid0.sk> <20060520105108.GC32550@osiris.uid0.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060520105108.GC32550@osiris.uid0.sk> User-Agent: Mutt/1.5.6i X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Miltered: at nez-perce with ID 446F9306.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 446F9304.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; bandel:01 in-berlin:01 ocaml:01 intel's:01 itanium:01 delayed:01 ocaml's:01 patching:01 patching:01 ocaml:01 posix:01 unix:01 20,:98 2006:98 2006:98 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.3 On Sat, May 20, 2006 at 12:51:08PM +0200, Jozef Kosoru wrote: > 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. [...] No. It would be a design flaw when future processors would make bigger problems. You may have missed the historical note from Xavier: OCaml is a BACK-port. What kind of problems would you run into, when backporting your current applications to a 16 or 8 Bit processor? Would you call that breaking code degned by flaw? The year 2k problem we have left behind, but the POSIX timer (derived from the Unix time) will overflow in 2038. So, he have some years to switch to 64 Bit platforms, before the year 2038 problem will make trouble ;-) Ciao, Oliver