[MLton-user] Raw conversion of 32 bits into Real32.t
Wesley W. Terpstra
wesley at terpstra.ca
Mon Jan 22 16:20:35 PST 2007
On Jan 23, 2007, at 1:04 AM, Henry Cejtin wrote:
> The problem of the thread-safe aspect of allocation outside a
> function call
> has already been solved. Look at the structure
> One in
> The signature is
> type 'a t
> val make: (unit -> 'a) -> 'a t
> val use: 'a t * ('a -> 'b) -> 'b
> The arg to make is the creation thunk. A single copy is made
> and saved,
> along with the thunk and a flag.
> When use is called, it checks if the single premade copy is in
> use. If it
> isn't then it passes it to its second arg. If it is then it makes
> a new one.
This is all well and good for the situation where there is a high
cost associated with the object creation. However, in Matthew's
example, the method was so small and its scope so narrowly defined,
that I think using 'One' is massively overkill.
I think my version (with the inline creation) should be preferable on
the grounds of simplicity and thread-safety. If things really need to
be optimized by the user, then your above solution is certainly
> It is way better than having to re-allocate things every time.
Ok, I understand that the vector gets allocated on the heap. But the
naive programmer in me says: this should have been allocated on the
stack, ala alloca()!
In fact, that programmer is not so naive: Doesn't MLton have all the
information it needs to realize that the array is allocated inside of
function scope, not returned, and never needed by a closure?
Therefore, it shouldn't be allocating it on the heap, but on the
stack. I'd think that this would improve performance of a wide-range
of methods, and make thread-safe code faster and simpler than
Matthew's non-threadsafe example.
More information about the MLton-user