---
This message is a formal comment which was submitted to [EMAIL PROTECTED],
following the requirements described at: http://www.r6rs.org/process.html
---
Name: Brad Lucier
email: [EMAIL PROTECTED]
Type of issue: Defect
Priority: Serious, if you're interested in performance
R6RS component: Bytevectors
Version of the report: Revised5.92 Report on the Algorithmic Language
Scheme - Standard Libraries
Summary: bytevector aliasing severely impedes optimizations
Description:
I presume that many people might want to use bytevectors as described
in this report to increase computational speed and decrease memory
requirements by avoiding boxing/unboxing of objects that might
otherwise be boxed when held in generic vectors. At least, I don't
see any other way to get this type of performance or reduce memory in
this way.
By having only one type of bytevector that aliases all of 32-bit
integers, 64-bit integers, 32-bit IEEE 754 numbers, and 64-bit IEEE
754 numbers, optimization opportunities for compilers are severely
degraded. One does not know, for example, whether storing a 64-bit
IEEE double into bytevector A changes the value of a 32-bit integer
read from bytevector B without actually checking whether A and B are
the same objects and whether the range of indices used to access A
and B overlap.
This very problem has been recognized by recent C standards, which
forbid such types of aliasing except by going through (char *). (The
proposed R6RS bytevectors would propose a problem for more than
Scheme->C compilers, however---it is a library design problem.) It
could be said by analogy that the proposed R6RS libraries offer
*only* a (char*) (more tamed than in C), which solves one small
class of problems (how to allow semi-portable, low-level translation
between data types that can be considered sequences of bytes; how to
write I/O device drivers; ...) while completely ignoring a much
larger and more important class of problems (allowing fast and memory-
efficient access to large arrays of homogeneous numerical data).
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss