Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Types (in arrays)

2 views
Skip to first unread message

Andrew Cooke

unread,
Mar 5, 2000, 3:00:00 AM3/5/00
to

Hi,

Can someone plesae explain (or tell me where I can find out) any of the
following queries.

I have a program that needs to store many arrays of words (16 bits).
When I realised that there were memory problems I started adding
element-type to make-array:
(make-array size :element-type '(integer (mod 65536))) ; 1
This didn't seem to reduce memory use so then I tried
(make-array size :element-type '(integer 0 65535)) ; 2
which did help once I realised that in one place I was using
(make-array size :element-type '(integerd 0 65535)) ; 3

My questions are really:
- How do I know which type specifiers are simple enough for a compiler
to understand the implications (1 clearly wasn't - although I may be
wrong in thinking it is a valid type specifier)?
- Why does case (3) fail silently?
- How are types used? There seem to be several different things going
on at once - memory size allocation, testing when new values are stored,
initial value allocation (I get zeroes rather than nill if the type is
numeric, for example).

(In the end I realised I could reduce the risk of typos by using
deftype).

Thanks,
Andrew
http://www.andrewcooke.free-online.co.uk/index.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Hidayet Tunc Simsek

unread,
Mar 5, 2000, 3:00:00 AM3/5/00
to
I don't know about other implementations but with CMUCL there are arrays
specialized
to these types (and perhaps some others that I don't know of):


(complex double-float)
(complex single-float)
double-float
single-float
(signed-byte 32)
(signed-byte 16)
(signed-byte 8)
(unsigned-byte 32)
(unsigned-byte 16)
(unsigned-byte 8)

What this means is (IMO);

1. aref is faster for these arrays
2. there is no consing with (setf (aref ...

e.g.
-----

(make-array 1000 :element-type '(signed-byte 32))

Regards,
Tunc

p.s. for further info I think you can read the internal docs for CMUCL.
I don't know about
other implementations.

Erik Naggum

unread,
Mar 6, 2000, 3:00:00 AM3/6/00
to
* Andrew Cooke <and...@andrewcooke.free-online.co.uk>

| I have a program that needs to store many arrays of words (16 bits).

the available types are then (unsigned-byte 16), (signed-byte 16), (mod
65536), (integer 0 65535), (integer -32768 +32767), etc, which all should
mean the same thing: 16 bits of allocated data per element of the array.
if they don't behave the same, you probably have a broken Common Lisp
implementation.

| My questions are really:
| - How do I know which type specifiers are simple enough for a compiler
| to understand the implications (1 clearly wasn't - although I may be
| wrong in thinking it is a valid type specifier)?

the function upgraded-array-element-type will return the internal type it
has deemed most optimal for the array element type you have requested.

| - Why does case (3) fail silently?

probably because the implementation only checks for types it knows, and
consider it risky to comment on stuff it doesn't know about.

| - How are types used? There seem to be several different things going
| on at once - memory size allocation, testing when new values are stored,
| initial value allocation (I get zeroes rather than nill if the type is
| numeric, for example).

this is a very big question. the simple answer is that the vendor has
made a number of decisions that are believed to give optimal performance,
both in time and space, given the type information you have provided.
now, this is not quite the useless answer it looks like, because it means
that each vendor will make "personal" decisions about what constitutes
"optimal performance" -- and these decisions will naturally differ quite
a bit from person to person. one rule of thumb prevails, however: useful
optimizations always reflect the capabilities of the aunderlying hardware,
so you have to have a fairly good grasp of how the implementation uses
machine resources to make the decisions. I'll leave it at that for now,
since this is issue that very quickly becomes suiteable for comp.arch.

#:Erik

Robert Monfera

unread,
Mar 6, 2000, 3:00:00 AM3/6/00
to

Andrew Cooke wrote:

> I get zeroes rather than nill if the type is numeric, for example

The Hyperspec says:

"If initial-element is not supplied, the consequences of later reading
an uninitialized element of new-array are undefined [...]"

Your zeros could be accidental and you shouldn't rely on it.
Initialization with zeros could alternatively be an
implementation-dependent and probably wasteful feature. Memory
allocation is infinitely faster than element initialization, even if
CISC processors (Pentium) have operations to fill a whole memory block
with a specified value.

ACL avoids extra work, even when interpreting top-level functions:

> (time (make-array 10000000
:element-type '(unsigned-byte 32)
:initial-element 0))
; cpu time (non-gc) 380 msec user, 0 msec system

> (time (make-array 10000000
:element-type '(unsigned-byte 32)
))
; cpu time (non-gc) 0 msec user, 0 msec system

A declared MAKE-ARRAY in LispWorks also returns quasi-random integers if
no initial-element is provided.

Non-numeric arrays are filled with NILs to avoid horrendous crashes due
to random numbers possibly being interpreted as pointers, while the
"undefined, but trustable" consequence of reading from an uninitialized
integer or float array is that its elements will be quasi-random
numbers.

Robert

Andrew Cooke

unread,
Mar 6, 2000, 3:00:00 AM3/6/00
to
In article <38C3F2CF...@fisec.com>,

Robert Monfera <mon...@fisec.com> wrote:
> Andrew Cooke wrote:
> > I get zeroes rather than nill if the type is numeric, for example
> "If initial-element is not supplied, the consequences of later reading
> an uninitialized element of new-array are undefined [...]"

Thanks for all the helpful replies (need to fix some code re the
above!).

Andrew

Raymond Toy

unread,
Mar 10, 2000, 3:00:00 AM3/10/00
to
>>>>> "Hidayet" == Hidayet Tunc Simsek <sim...@EECS.Berkeley.Edu> writes:

Hidayet> I don't know about other implementations but with CMUCL
Hidayet> there are arrays specialized to these types (and perhaps
Hidayet> some others that I don't know of):


Hidayet> (complex double-float)
Hidayet> (complex single-float)
Hidayet> double-float
Hidayet> single-float
Hidayet> (signed-byte 32)
Hidayet> (signed-byte 16)
Hidayet> (signed-byte 8)
Hidayet> (unsigned-byte 32)
Hidayet> (unsigned-byte 16)
Hidayet> (unsigned-byte 8)

Add
(unsigned-byte 4)
(unsigned-byte 2)
(unsigned-byte 1)

(signed-byte 30) (same as fixnum)

Ray


0 new messages