From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Llorens Newsgroups: gmane.lisp.guile.devel Subject: Re: vectors are something else Date: Tue, 16 Apr 2013 06:10:21 +0200 Message-ID: <9282A433-1C3C-4D65-BDCB-9824F9227815@bluewin.ch> References: <9D053760-46BC-46F1-B84D-07902E777FF2@bluewin.ch> <87haj72q08.fsf@tines.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1366085429 31990 80.91.229.3 (16 Apr 2013 04:10:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Apr 2013 04:10:29 +0000 (UTC) Cc: guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Apr 16 06:10:33 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1URxE1-00089S-0o for guile-devel@m.gmane.org; Tue, 16 Apr 2013 06:10:33 +0200 Original-Received: from localhost ([::1]:48065 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URxE0-0002cq-9W for guile-devel@m.gmane.org; Tue, 16 Apr 2013 00:10:32 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45128) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URxDv-0002ca-7I for guile-devel@gnu.org; Tue, 16 Apr 2013 00:10:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1URxDu-0003gB-2q for guile-devel@gnu.org; Tue, 16 Apr 2013 00:10:27 -0400 Original-Received: from zhbdzmsp-smta17.bluewin.ch ([195.186.99.133]:38867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URxDt-0003g4-S4 for guile-devel@gnu.org; Tue, 16 Apr 2013 00:10:25 -0400 Original-Received: from [195.186.227.130] ([195.186.227.130:37364] helo=zhhdzmsp-smta12.bluewin.ch) by zhbdzmsp-smta17.bluewin.ch (envelope-from ) (ecelerity 2.2.3.47 r(39824M)) with ESMTP id 31/E2-08134-F2FCC615; Tue, 16 Apr 2013 04:10:23 +0000 Original-Received: from [10.0.1.10] (81.62.254.89) by zhhdzmsp-smta12.bluewin.ch (8.5.142) (authenticated as dll@bluewin.ch) id 510085B007216564; Tue, 16 Apr 2013 04:10:23 +0000 In-Reply-To: <87haj72q08.fsf@tines.lan> X-Mailer: Apple Mail (2.1085) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 195.186.99.133 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16257 Archived-At: On Apr 16, 2013, at 04:00, Mark H Weaver wrote: >> [1] have vector- ops only accept vector- types. This removes = container >> type dispatch from the vector- ops but not from the array- ops. The >> last patch set I've sent to the list goes in this direction. It >> matches the behavior of other vector-like types such as bytevectors >> and strings. >=20 > I very much favor this approach, but unfortunately I don't think we = can > do it in 2.0. It'll have to wait until 2.2. What should we do then about the consistency bugs? like vector? being #f = on something that is accepted by vector-ref and so on. Did you have a = look at the table I posted? > I consider this option completely unacceptable. Arrays are much more > complex than vectors, and will inevitably be *much* slower in the = common > case where the compiler doesn't know much. ... > Most egregiously, > 'make-shared-array' requires that array references apply an arbitrary > affine transformation that's unknown at compile time, which means > multiplications and additions for each index. make-shared-array itself is a very slow function and I'd like to have = some alternatives, but it's only called when setting up the shared = array. In any case, it's not slow because of any multiplications, but = because of how much it conses. You overestimate (by a lot) the cost of the index computation. One works = on arrays by looping over them. In these loops the strides are always = constant. No matter the rank of the array, in the inner loop only one = index moves. The cost of this stepping is negligible on any scenario = that isn't hugely contrived. Things like traversal order and memory = order have a much larger impact on performance. 90% of the reason why = Guile arrays are dog slow is that they've been programmed with no = concern for efficiency. The other 10% is the need to do type dispatch on = various kinds of containers and various types of elements. (These = numbers are invented.) > Don't get me wrong: I'm all in favor of providing flexible, generic, > extensible procedures. They have their place. I think that's why > there's still a justification for keeping 'generalized-vectors' = around. They didn't do anything that the array functions didn't do just as well. = Plus they were buggy =97they are buggy in stable-2.0. And the names took = half the screen. > However, efficiency demands that we also have simple, non-generic, > non-extensible procedures as well. IMO, we should keep the vector, > bitvector, and bytevector procedures as simple as possible. Other than the bizarre idea that arrays have to be slow, I think this is = a sensible position. After all, arrays have both an array descriptor and = a reference to linear storage, so there must be a type for this linear = storage. (E.g. in stable-2.0, vector- operations take either arrays, in = a buggy way, or the underlying storage type, which is called 'simple = vector' and isn't exposed to Scheme.) What's your take on Daniel Hartwig's position? For example a and b on = the table I posted =97b is an array, but it prints as #(2 4). How do you = justify forbidding vector-ref for something that prints #(2 4) ? Thanks for you comments, Daniel