From owner-freebsd-arch@FreeBSD.ORG Wed Jul 14 10:06:10 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 268EA16A4CF for ; Wed, 14 Jul 2004 10:06:10 +0000 (GMT) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEBCE43D2F for ; Wed, 14 Jul 2004 10:06:09 +0000 (GMT) (envelope-from metal_man@mail.ru) Received: from [217.118.66.254] (port=31826 helo=METALLER) by mx1.mail.ru with smtp id 1BkgeJ-000OHu-00; Wed, 14 Jul 2004 14:06:05 +0400 Message-ID: <000101c4698a$345f4a40$ef2014ac@METALLER> From: "Dmitriy Startsev" To: "Jay Sern Liew" , References: <1089567603.746.45.camel@athlon> Date: Wed, 14 Jul 2004 14:06:11 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 FL-Build: Fidolook 2004 (HL) 6.0.2600.32000 - 17/4/2004 06:54:21 Subject: Re: increased machine precision for FreeBSD apps? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2004 10:06:10 -0000 Hello, Jay! You wrote to on Sun, 11 Jul 2004 12:40:04 -0500: JSL> This is probably more of an organizational issue than an JSL> architectural one. In the event of running applications with heavy JSL> floating point arithmetic (e.g. scientific computation apps for one, JSL> encryption algorithms, compression, .. etc ), would it be a good idea JSL> to decrease rounding errors by increasing the data type size? JSL> e.g. When a programmer declares a floating point variable, the JSL> compiler/assembler allocates twice(or a multiple of) the space needed, JSL> hence increasing the precision(and better approximation?). I realize JSL> this is really just a trade off with execution speed and/or JSL> efficiency, perhaps unsuitable for real time calculations, but better JSL> for those who don't mind waiting a little for better results, with JSL> less the hardware. As a small peek into the future if this thing JSL> doesn't sound like herecy, we _could_ implement this so that it is JSL> transparent to the programmer(doing it at the compiler/assembler JSL> level), none of the ports would need to be rewritten, and could JSL> potentially benefit from the increased machine precision(where JSL> desired). Just an idea for FreeBSD to knock on the scientific JSL> community's door. (If 2.5 mil web hosts trusts FreeBSD for JSL> reliability, why can't the more mathematically inclined community?) JSL> I realize that the real scientists(read: well funded, by the big JSL> wigs) would have at their disposal computers that won't be needing JSL> this(although they could benefit from this), this would be great for JSL> home-brewed calculations, maybe students(computer scientists, JSL> mathematicians, chemists, biologists, meteorologists, .. ), or just JSL> any DIY-ist. This isn't really a new idea, perhaps comparable to JSL> x86-64; sure x86-32's may not have the 64-bit physical address space, JSL> but they can still have the 64-bit(or more) precision, right? I JSL> apologize if this suggestion has already been brought up before. (I'm JSL> not only the kind who speaks, I'd aid in the development of this). IMHO this is a bad idea. Being a programmer myself I have to say I won't ever use a compiler that generates code different from what I expect. Even M$ compiler doesn't take THAT much upon itself:) When someone writes a program, he considers computational precision it requires and implements it using standard C types. If double is not enough, one could use long double. If even that is not enough then one have to consider using different algorithm rather than to try to increase precision. For most of the ports, increased precision will not give any benefits, but will only decrease performance and possibly introduce some serious bugs in software that relies on particular data type sizes. BTW, about x86-64: default operand size is still 32 bits on this architecture (and 64 bit types can be used on 32 bit machines as well). There are international standards related to machine data type representation, compilers, etc. Let's stick to them as much as possible. With best regards, Dmitriy Startsev.