libera/#sicl - IRC Chatlog
Search
9:55:40
beach
I believe all I have left for `ctype' in terms of SICL configuration is the definition of +CLASS-ALIASES+.
9:58:56
heisig
beach: The SIMD programming is progressing splendidly, mostly because I do it instead of working on my thesis :)
10:01:47
heisig
The other thing I should announce is that I am in a hospital right now, for a scheduled surgery. Nothing terrible, but I might not be that active for the next few days.
13:15:35
beach
Bike: In +CLASS-ALIASES+, is there a particular reason to use types such as EXT:INTEGER8 rather than the equivalent standard (INTEGER ...) type?
13:16:59
Bike
well, in clasp those are the upgraded types. eliminating those and using standard types might be nice, sure
13:17:35
beach
No, I mean, does anything bad happen to me if I write (UNSIGNED-BYTE 32) in that position for SICL?
13:20:33
beach
So my question was whether I had to define such atomic types, and the answer is "no". Thank you!
13:23:13
Bike
maybe i should explain a little more. the class aliases are basically like deftype definitions - e.g. when the system tries to parse the specifier SIMPLE-VECTOR-FIXNUM in clasp, it looks it up, sees (SIMPLE-ARRAY FIXNUM (*)), and parses that instead. the difference with deftype is that they're also checked when specifier-type is given a class with that name.
13:23:31
Bike
it's all so that operations like (subtypep (find-class 'whatever-array-class) 'array) work correctly.
13:25:10
Bike
there is a requirement on upgraded array element types that they're comparable with EQUAL, but i could probably loosen that if necessary
13:26:14
jackdaniel
I think that if you have a float as a class in /any/ implementation, making its atomic subtypes {short,single,double,long}-float (whichever are appropriate) is not hard
13:27:30
Bike
beach: when parsing types, yes. given that u-a-e-t kind of inherently needs to check subtypep in complex cases, there is a bit of a metacircularity issue there
13:28:22
Bike
well, the type system needs upgraded-array-element-type to work with array types correctly
13:28:38
Bike
i think what one could do is have upgraded-array-element-type handle simple cases with a table and then use subtypep otherwise
13:29:38
Bike
"the type system needs upgraded-array-element-type in order to work[...]" i should say
13:32:26
Bike
i think it only calls it in one place, anyway. once the type specifier is parsed it does not use u-a-e-t again.
13:32:59
Bike
still, it needs a fully correct u-a-e-t to parse arbitrary types, and a fully correct u-a-e-t pretty much needs to call subtypep
13:33:57
Bike
you can just write u-a-e-t in terms of ctype subtypep. the recursion bottoms out, since the subtypep is of the element types
13:35:08
Bike
and that won't involve parsing an array type, so you won't go back into u-a-e-t. right.
13:35:49
Bike
i remember thinking this through before but i didn't write it down. i should expand on the section of the readme about using it as sub/typep. i haven't really done it beyond a hotswap in clasp to check ansi-tests
13:37:59
Bike
i don't understand what you mean. ctype needs to be able to parse things like (array (and (satisfies foo) fixnum))
13:39:10
beach
OK, if I am able to implement u-a-e-t by doing (cond ((subtypep ... '(unsigned-byte 32)) ...) ((subtypep ... '(signed-byte 32)) ...) ...)
13:40:50
Bike
i suppose there's no reason it couldn't. i was basically focused on typep and subtypep. there are various implementation choices one could make for efficiency reason, but ctype has to make some of those already
13:42:11
beach
OK, let me ask this as a question then... What would an implementation do differently in order to implement u-a-e-t?
13:42:58
Bike
could handle simple cases (fixnum, unsigned-byte whatever) up front to avoid the overhead of subtypep.
13:44:26
Bike
of course, there are other optimizations ctype could do or support doing but doesn't yet, like typep on constant types
13:44:48
Bike
or caching specifier-type, which it really ought to do, but which sort of implicates multithreading issues a little
13:45:10
beach
OK, so now I wonder whether ctype could supply that simple definition somehow, and the client implementation can manage the cache/table and call ctype for complicated cases.
13:48:30
Bike
once someone is actually using ctype there will be some direction and motivation for improvements, of course :)
13:53:46
beach
I should take this opportunity to add some missing array classes to SICL that I may have missed. Like for complex single float and complex double float.
14:03:15
beach
I can see why drmeister wanted to take the Common Lisp code from an existing implementation. There are literally thousands of tiny little details to think about and to fill in. Not that this was a real option for SICL, but I think I underestimated the number of such details.
14:30:28
pjb
We can add an infinite number of array classes depending on types. We can optimize for each of `(unsigned-byte ,(expt 2 (* 8 n))); we could even optimize storage for non 8 multiples powers of 2…
14:31:20
pjb
But only number and character arrays can be specialized like that. The other lisp objects being references, they couldn't be stored inside the array (without extensive global analysis of the program).
14:32:25
pjb
Now, "global" is relative. If we can analyse the data flow and ensure that data is not leaked outside of a given function, then we could easily allocate arrays of structures, or array of conses…
14:33:24
drmeister
beach: I agree with you. In the case of specialized arrays though - I had to implement that all myself.
14:33:55
beach
pjb: I agree, and I know of people who want stuff like that, but I am going to be very reluctant to adding such things.
14:35:08
pjb
You may reject it. But I think it could be a nice opportunity for optimization if an implementation to provided it. Notably an array of defstruct means that each slot of the structure stored in the array could be of different size.
14:36:16
pjb
Notably, those 5 optimized cases would be nice if we want to exchange those arrays or this kind of storage with external code (FFI, memory mapped, etc).
14:37:19
beach
Things are so easy to add to SICL, given its structure, so I don't see why things like that should be in the main repository.
15:20:41
beach
So what I (or someone) should do is to group together all the SICL code required for one particular array/vector type into a single file, and add instructions on how to add more such types.
15:49:49
pjb
shka: memory could be shared with other things than processes, eg. with device drivers. eg. a video buffer.