[info-mcl] digitool (MCL) / clozure (OpenMCL)

[Toomas Altosaar]

>At 10:26 AM +0300 10/11/07, Toomas Altosaar wrote:
>>  >  > 4. I would like to see the compiler improved. In particular, I would
>>>>   like to see math be faster, especially floating point math.
>>>
>>>I would like to second these requests - being able to do reasonably
>>>fast floating point math on data allocated in a static region would be
>>>quite useful for graphics applications in general.
>>
>>And for any vector/matrix-based digital signal processing as well.
>>Currently in MCL we make calls to external frameworks written in C
>>with XCode. We need guarantees that memory isn't moved while the call
>>to C is in progress since C writes back directly to the addresses of
>>the vector(s) supplied in the FFI call.
>>
>>If it is technically gc-wise feasible, some macro that would inhibit
>>memory from being moved for the object in question:
>>
>>(with-gc-inhibited (vector1 vector2 vector3)
>>    (some-FFI-op vector1 vector2 vector3))
>
>I don't think this would be the correct long term approach. Turning 
>the GC off is like tuning interrupts off inside an OS kernel. You 
>really try not to do that. It's bad for performance and it effects 
>other threads in bad ways. It doesn't scale. There are other reasons 
>as well.

I was infering that gc could run but would not move/relocate the 
specific objects specified, in this example the three vectors. I was 
not suggesting that egc/gc would be turned off globally. But it might 
be technically difficult to come up with a gc that could provide this 
functionality efficiently.

>  >If not, then being able to allocate the vectors in static regions
>>would be the next best thing.
>
>This is the correct approach in my opinion. I am not sure this 
>shouldn't be the default for floating point vectors. You can still 
>GC these heaps you just can't compact them or move the objects.
>
>leb

OK.