From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=1.0 required=5.0 tests=AWL,SPF_FAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 53FF9BC37 for ; Tue, 12 May 2009 12:04:54 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwBAHDmCEpQW+UCe2dsb2JhbACXEwEBFiIEtF6EAgU X-IronPort-AV: E=Sophos;i="4.41,181,1241388000"; d="scan'208";a="39820366" Received: from main.gmane.org (HELO ciao.gmane.org) ([80.91.229.2]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 12 May 2009 12:04:42 +0200 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M3oqn-0007j9-0y for caml-list@inria.fr; Tue, 12 May 2009 10:04:41 +0000 Received: from ks300734.kimsufi.com ([91.121.65.225]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 May 2009 10:04:41 +0000 Received: from sylvain by ks300734.kimsufi.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 May 2009 10:04:41 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Sylvain Le Gall Subject: Re: Ocamlopt x86-32 and SSE2 Date: Tue, 12 May 2009 10:04:26 +0000 (UTC) Message-ID: References: <20090511043120.976EBBC67@yquem.inria.fr> <4A09434D.3020102@inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ks300734.kimsufi.com User-Agent: slrn/pre0.9.9-102 (Linux) Sender: news X-Spam: no; 0.00; le-gall:01 ocamlopt:01 packagers:01 libc:01 libc:01 afaik:01 runtime:01 lenny:98 lenny:98 wrote:01 compile:01 compile:01 exceptions:01 emulate:01 inefficient:02 On 12-05-2009, Xavier Leroy wrote: > > Sylvain Le Gall: >> If INRIA choose to switch to SSE2 there should be at least still a way >> to compile on older architecture. Doesn't mean that INRIA need to keep >> the old code generator, but should provide a simple emulation for it. In >> this case, we will have good performance on new arch for float and we >> will still be able to compile on old arch. > > The least complicated way to preserve backward compatibility with > pre-SSE2 hardware is to keep the existing x87 code generator and bolt > the SSE2 generator on top of it, Frankenstein-style. Well, either > that, or rely on the kernel to trap unimplemented SSE2 instructions > and emulate them in software. This is theoretically possible but I'm > pretty sure neither Linux nor Windows implement it. > I was thinking (if it is possible) to use simple "function call" for doing float operation. This will be very inefficient, but will provide a very simple compatible layer. > > To finish: I'm still very interested in hearing from packagers. Does > Debian, for example, already have some packages that are SSE2-only? > Are these packages specially tagged so that the installer will refuse > to install them on pre-SSE2 hardware? What's the party line? > The more obvious package I see, is the linux kernel or the libc6: http://packages.debian.org/lenny/linux-image-2.6.26-2-486 http://packages.debian.org/lenny/linux-image-2.6.26-1-686-bigmem http://packages.debian.org/lenny/libc6 http://packages.debian.org/lenny/libc6-i686 AFAIK, there is no way for the package manager to do a real difference (no tag). However, the installer has some clue about which one to choose and install the best one for linux and libc6. Once installed, it is always updated in the good way, because the arch is embeded into the package name. I think linux and libc6 should be considered as exceptions, because they really provide an important benefit for overall optimization. For other package, if there is possible optimization, a version with and without optimization is embedded into the package and chosen at runtime. Example libavcodec provide i686 and i486 version: http://packages.debian.org/sid/i386/libavcodec52/filelist So in conclusion, there is always a "default" non SSE2 alternative for package that can provide an optimized version. I don't know any package that are SSE2-only. Im my opinion, Debian will probably refuse to ship a package that only provide SSE2-only version (but I am talking from my point of view). Regards Sylvain Le Gall