Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 23 Feb 2003 15:40:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 23 Feb 2003 15:40:54 -0500 Received: from franka.aracnet.com ([216.99.193.44]:16876 "EHLO franka.aracnet.com") by vger.kernel.org with ESMTP id ; Sun, 23 Feb 2003 15:40:53 -0500 Date: Sun, 23 Feb 2003 12:50:59 -0800 From: "Martin J. Bligh" To: Xavier Bestel cc: Linux Kernel Mailing List Subject: Re: Minutes from Feb 21 LSE Call Message-ID: <16920000.1046033458@[10.10.2.4]> In-Reply-To: <1046031687.2140.32.camel@bip.localdomain.fake> References:

<20030223082036.GI10411@holomorphy.com> <1046031687.2140.32.camel@bip.localdomain.fake> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 900 Lines: 20 >> And the baroque instruction encoding on the x86 is actually a _good_ >> thing: it's a rather dense encoding, which means that you win on icache. >> It's a bit hard to decode, but who cares? Existing chips do well at >> decoding, and thanks to the icache win they tend to perform better - and >> they load faster too (which is important - you can make your CPU have >> big caches, but _nothing_ saves you from the cold-cache costs). > > Next step: hardware gzip ? They did that already ... IBM were demonstrating such a thing a couple of years ago. Don't see it helping with icache though, as it unpacks between memory and the processory, IIRC. M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/