From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan Schukat Newsgroups: gmane.lisp.guile.bugs Subject: bug#14599: An option to make vector allocation aligned Date: Mon, 17 Jun 2013 12:04:05 +0200 Message-ID: <51BEDF15.4050302@email.de> References: <51B87998.9060402@email.de> <87a9mvide2.fsf@gnu.org> <51B8E4B7.9060306@email.de> <874nd2gmsq.fsf@gnu.org> <51BAD514.4090002@email.de> <8761xgevcd.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1371463521 1251 80.91.229.3 (17 Jun 2013 10:05:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Jun 2013 10:05:21 +0000 (UTC) Cc: 14599@debbugs.gnu.org To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Mon Jun 17 12:05:20 2013 Return-path: Envelope-to: guile-bugs@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 1UoWJL-0001MU-SN for guile-bugs@m.gmane.org; Mon, 17 Jun 2013 12:05:20 +0200 Original-Received: from localhost ([::1]:57098 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UoWJL-0000oF-1U for guile-bugs@m.gmane.org; Mon, 17 Jun 2013 06:05:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UoWJC-0000nC-34 for bug-guile@gnu.org; Mon, 17 Jun 2013 06:05:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UoWJ5-0005lm-Hn for bug-guile@gnu.org; Mon, 17 Jun 2013 06:05:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55557) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UoWJ5-0005kg-Ee for bug-guile@gnu.org; Mon, 17 Jun 2013 06:05:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1UoWJ4-0004pa-Je for bug-guile@gnu.org; Mon, 17 Jun 2013 06:05:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jan Schukat Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Mon, 17 Jun 2013 10:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14599 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 14599-submit@debbugs.gnu.org id=B14599.137146345818476 (code B ref 14599); Mon, 17 Jun 2013 10:05:02 +0000 Original-Received: (at 14599) by debbugs.gnu.org; 17 Jun 2013 10:04:18 +0000 Original-Received: from localhost ([127.0.0.1]:49873 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1UoWIL-0004nv-At for submit@debbugs.gnu.org; Mon, 17 Jun 2013 06:04:17 -0400 Original-Received: from mout.web.de ([212.227.17.11]:52478) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1UoWII-0004nc-20 for 14599@debbugs.gnu.org; Mon, 17 Jun 2013 06:04:15 -0400 Original-Received: from [192.168.0.27] ([85.177.95.148]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0M5OYl-1UOhwH3YEB-00zXjr; Mon, 17 Jun 2013 12:04:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 In-Reply-To: <8761xgevcd.fsf@gnu.org> X-Provags-ID: V03:K0:R8QZGjrHPZ5vxEW5U2itUgta0u63x51zuiDl1PsJyaczCiWQQ5Z FO+zoQ/cY0RijRNItiBwINtu0Y5volVGNjoR8ekAR5dD3SUSSSMwKSn0bh74MACTr8G1tdr 2Hx0bsZdc1OoXm6/nqVTHyAKeorMsATa07WedWKtsOMdTKoVm+cOrqNqrSYkTbYBEpcfqWD LiVyp41HPR+5LRSmI3Z0g== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:7178 Archived-At: On 06/14/2013 02:21 PM, Ludovic Courtès wrote: > Jan Schukat skribis: > >> The more I think about it and hear what you have to say, the more I >> think alignment just needs to be tied to the type of the uniform >> array. > I think it would be wrong. An array of floats is an array of floats, > regardless of its alignment. For floats nothing would change anyway. Those are 4byte data types with 4byte alignment already. As for the larger types, you can still make them in any alignment with the take functions. Just the default would the optimized one when you add padding, and that's what it should be, since the scheme programmer doesn't care about the underlying memory layouts as much as the C programmer does. In normal guile uniform vector use you are completely oblivious to the underlying vector implementation, apart from the performance. In short: an array of floats is still an array of floats, and you can create them at any alignment, although cumbersomely. But the very point if creating arrays of native types is to better use the underlying hardware. And not taking advantage of alignment there unless you absolutely can't is negligent at best. >> Also, now I lean more towards switching to 2.2 for myself and >> implement it on there, because as Ludovic said, the compiling will >> possibly preserve alignment there better. > Well yeah, though you’d still need to come up with an annotation for > that, and I’m not enthusiastic about changing the read syntax for that > purpose. You don't need a special annotation if the default alignment is the native alignment of the native type. If you create arrays of native types that is what you want in the vast majority of cases. Overriding that should be the extra work and forced by external requirements, not by internal coincidental implementation details. And the interfaces to do that are already there. I wanna use native SIMD types, which are obviously less portable, but in the end where they do exist they are all more or less the same in memory layout: 4 32bit ieee floats, 4 32bit ints or 2 ieee doubles, all preferably aligned at 128 bit. That's true for sse, altivec and neon on x86, power and arm respectively. I can see why you wouldn't want SIMD types in the core modules. I can also see why you wouldn't want to change existing read syntax. What I can't see is why you wouldn't want native type arrays in native alignment by default. There is no downside, and the implementation makes doing that trivial. And having a module of uniform SIMD type arrays/vectors could be very valuable. I'll probably do that as an extension then, with a #, reader. Would just be a lot of code duplication and less nice. > > Now, I think the compiler should support a generic annotation mechanism, > to allow users to specify various things (like ‘declare’ in some > implementations.) That could be one possible use. > > Ludo’. Yes, that would have a lot of utility. Regards Jan Schukat