unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* Re: propose deprecation of generalized-vector-*
@ 2013-02-28 23:04 Nelson H. F. Beebe
  2013-03-04 12:48 ` Aharon Robbins
  0 siblings, 1 reply; 33+ messages in thread
From: Nelson H. F. Beebe @ 2013-02-28 23:04 UTC (permalink / raw)
  To: guile-devel; +Cc: Arnold Robbins, beebe

If guile introduces full-fledged support of arrays for numeric
computing, and for communicating with external libraries, such as the
currently-moribund Guile-numerics interface to GNU Scientific Library
(GSL), libsndfile, FFTW, and LAPACK

	http://www.nongnu.org/guile-num/

please do not forget, as higher-level language programmers too often
do, that array storage order matters a GREAT DEAL for efficiency.

Modern processors operate in registers up to 500x faster than on
(DRAM) memory, and cache (SRAM) is about 10x to 50x faster than DRAM.
Thus, if you use Fortran column-major order (first subscript varying
most rapidly), it can be MUCH faster to compute down the columns than
to compute across rows.  The C/C++ languages use row-major order (last
subscript varying most rapidly), so for them, the situation is
reversed: row traversals are preferred over column traversals.

Java really screwed things up by using an arrays-of-arrays-of-...
storage model, so MxN rectangular matrix data are spread over M or N
separate contiguous vectors allocated at arbitrary locations in
memory.  With that arrangement, and Java's requirement that array
accesses must be accompanied by mandatory bounds checks, it is
difficult to make good use of cache.  That serious deficiency is why
IBM introduced new contiguous-array classes for Java, and why the
(seemingly-now-defunct) Java Grande project was started:

	http://www.javagrande.org/
	http://en.wikipedia.org/wiki/Criticism_of_Java

The bounds-checking overhead can be reduced at a lower level: see

	Implicit array bounds checking on 64-bit architectures
	http://doi.acm.org/10.1145/1187976.1187982

For any scripting language that wishes to communicate array data with
external libraries written in other languages, it seems desirable to
offer support for remapping of (possibly-associative) arrays in the
scripting language to contiguous arrays in both row-major and
column-major order, with user-specified initializers for unset
elements.  That way, huge amounts of library code in Fortran, C, and
C++ become accessible.  The reverse mappings back from the external
library to the scripting language are also needed. If arrays are
handled with some generality in the latter, the library return might
not even require copying any numerical data, just updating some
metadata that record how array elements are to be found.

The GNU gawk developers are currently working on similar extensions to
the code world outside the scripting language; it would make sense for
both gawk and guile groups to be aware of the efforts of the other:

	https://lists.gnu.org/mailman/listinfo/gawk-devel

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe@math.utah.edu  -
- 155 S 1400 E RM 233                       beebe@acm.org  beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------



^ permalink raw reply	[flat|nested] 33+ messages in thread
[parent not found: <mailman.153.1351958430.10005.guile-devel@gnu.org>]
[parent not found: <mailman.191.1348070449.18828.guile-devel@gnu.org>]
* propose deprecation of generalized-vector-*
@ 2012-09-18 14:49 Daniel Llorens
  2012-09-19 12:02 ` Peter TB Brett
  2012-11-02 23:27 ` Ludovic Courtès
  0 siblings, 2 replies; 33+ messages in thread
From: Daniel Llorens @ 2012-09-18 14:49 UTC (permalink / raw)
  To: guile-devel


Hello,

today I filed a bug on generalized-vector->list

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12465

I remember similar bugs in the past, and I'm thinking that these functions are redundant since we have array-ref, array->list, and so on, which also work on strings, uniform vectors, etc.

The only generalized-vector-? function that doesn't have a direct array-? correspondence is generalized-vector-length. However, even for arrays of rank > 1 it is often convenient to have a function such as

(array-length a) = (car (array-dimensions a))

or maybe

(array-length a) = (fold * 1 (array-dimensions a))

Personally I'd favor the first as there's nothing to compute, but either would work to replace generalized-vector-length.

Possible objections:

— generalized-vector-? may be marginally faster than array-?

Both need to do a bunch of type checks and dispatching, and generalized-vector-? needs to check rank anyway, so I'm guessing this doesn't matter. We could do some benchmarking.

— generalized-vector-? acts as an extra check on rank

array-ref will flag rank errors, so this objection applies only to -length and ->list. I do not think this is important because it's usually clear from the code whether you're dealing with arrays of rank > 1 or not. But on this I'd like to hear from users of generalized-vector-?.

TLDR, I propose to remove the generalized-vector-? functions since the array-? set can replace them.

Regards,

	Daniel





^ permalink raw reply	[flat|nested] 33+ messages in thread

end of thread, other threads:[~2013-03-04 12:48 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-28 23:04 propose deprecation of generalized-vector-* Nelson H. F. Beebe
2013-03-04 12:48 ` Aharon Robbins
     [not found] <mailman.153.1351958430.10005.guile-devel@gnu.org>
2012-11-03 16:52 ` Daniel Llorens
2012-11-03 21:10   ` Ludovic Courtès
2013-01-21 16:11     ` Andy Wingo
2013-01-22 14:31       ` Daniel Llorens
2013-01-22 18:31         ` Daniel Llorens
2013-01-22 20:52           ` Andy Wingo
2013-01-22 23:27             ` Daniel Llorens
2013-01-23  9:20               ` Andy Wingo
2013-01-23 14:55             ` Ludovic Courtès
2013-01-23  9:06         ` Andy Wingo
2013-01-23 12:20           ` Daniel Llorens
2013-02-18 15:55             ` Andy Wingo
2013-02-18 16:05               ` Noah Lavine
2013-02-18 16:25                 ` Mike Gran
2013-02-18 16:29                   ` Noah Lavine
2013-02-18 17:11                     ` David Pirotte
2013-02-18 17:17                       ` Mike Gran
2013-02-18 23:57                   ` Daniel Hartwig
2013-02-21  1:13               ` Daniel Llorens
2013-02-22  0:22                 ` Noah Lavine
2013-02-28 19:10                   ` Daniel Llorens
2013-03-01  2:42                     ` Noah Lavine
2013-03-01  3:46                       ` Noah Lavine
2013-03-01  9:01                       ` Daniel Llorens
2013-03-01  9:44                         ` Andy Wingo
2013-03-04  2:27                         ` Noah Lavine
2013-02-18 15:40           ` Andy Wingo
     [not found] <mailman.191.1348070449.18828.guile-devel@gnu.org>
2012-09-19 17:20 ` Daniel Llorens
  -- strict thread matches above, loose matches on Subject: below --
2012-09-18 14:49 Daniel Llorens
2012-09-19 12:02 ` Peter TB Brett
2012-11-02 23:27 ` Ludovic Courtès

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).