|Anonymous | Login | Signup for a new account||2018-01-22 11:27 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006180||OCaml||back end (clambda to assembly)||public||2013-09-16 18:50||2015-12-11 19:25|
|Target Version||Fixed in Version||4.02.0+dev|
|Summary||0006180: Efficient creation of float arrays|
|Description||Would it be possible to provide a primitive that can efficiently allocate a block of a given length with a double tag without initializing its contents (which won't be scanned anyway)? This could then be exposed e.g. in the Array-module as follows:|
val alloc_floats : int -> float array = "%alloc_floats"
Allocating float arrays this way could speed up some numeric code. Users who need to optimize allocation performance of pure, mutable float records would also benefit.
|Tags||No tags attached.|
|Correction: I meant to say "double array tag", not "double tag".|
Wish granted, commit 14156 on trunk. The new function is Array.make_float (don't hesitate to suggest a better name!).
Speed is almost doubled for code such as:
let x = 10000000
let y = 16
let () =
for i = 1 to x do
let a = Array.create y 0. in
for j = 0 to y - 1 do a.(j) <- float j done
Of course, this will be diluted for code performing something useful.
(It might be interesting to see where we would be performance-wise with a version of Array.make_float which initializes the array to 0.)
|Aren't there security concerns with letting users access uninitialized memory? If the initialized-to-0 version isn't much slower, I would say it is a more reasonable choice.|
|There is already String.create. An argument for initializing to 0 is rather one of predictability to me (and it is also a useful behavior in many cases).|
@gasche: I don't think that float arrays are in any way risky in that respect. That said, I do usually initialize float arrays during testing, but with NANs, not with zeros. The reason is that an incorrect use of the array (reading uninitialized parts) would then likely propagate the NANs everywhere, making the bug more obvious.
Thanks for the patch, Alain!
I've just seen that the new C-function "caml_make_float_vec" contains the code:
if (wsize == 0)
This seems redundant, because the subsequent call to "caml_alloc" will perform the exact same test. I think it can be safely dropped, slightly increasing performance for most use cases. Another optimization would be to just manually inline the contents of "caml_alloc" and specialize its body for float tags (i.e. dropping the redundant tests for field initialization).
|Thanks. I've followed your suggestion of inlining caml_alloc in caml_make_float_vect (commit 14338 on trunk).|
|2013-09-16 18:50||mottl||New Issue|
|2013-09-16 18:51||mottl||Note Added: 0010360|
|2013-09-17 13:39||frisch||Assigned To||=> frisch|
|2013-09-17 13:39||frisch||Status||new => assigned|
|2013-09-17 14:02||frisch||Note Added: 0010364|
|2013-09-17 14:02||frisch||Status||assigned => resolved|
|2013-09-17 14:02||frisch||Fixed in Version||=> 4.02.0+dev|
|2013-09-17 14:02||frisch||Resolution||open => fixed|
|2013-09-17 15:11||gasche||Note Added: 0010365|
|2013-09-17 15:34||frisch||Note Added: 0010366|
|2013-09-17 16:02||mottl||Note Added: 0010368|
|2013-11-29 23:51||mottl||Note Added: 0010679|
|2013-12-04 10:38||frisch||Note Added: 0010690|
|2015-12-11 19:25||xleroy||Status||resolved => closed|
|2017-02-23 16:35||doligez||Category||OCaml backend (code generation) => Back end (clambda to assembly)|
|2017-02-23 16:44||doligez||Category||Back end (clambda to assembly) => back end (clambda to assembly)|
|Copyright © 2000 - 2011 MantisBT Group|