You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 7495 Reporter:@mmottl Assigned to:@damiendoligez Status: acknowledged (set by @mshinwell on 2017-03-07T12:33:34Z) Resolution: open Priority: normal Severity: minor Version: 4.04.0 Category: runtime system and C interface Monitored by:@mshinwell@mmottl
Bug description
Consider the following code:
let()=letopenBigarrayinfor _i =1to100_000dolet vec =Array1.create float64 c_layout 1_000_000in(* Makes sure that physical memory is actually allocated *)Array1.fill vec 0.done
This code will let memory consumption quickly go into the GB range. A comparable implementation using float arrays will stay stable in the low MB range:
I remember that this is a long-standing problem, probably the same as #4616, and likely affects custom block allocation in general. Not sure whether it's already tracked in another still active issue. Since the GC will likely undergo significant changes in the near future due to attempts to parallelize it, I think this issue should remain on people's mind. Some practical numerical code can run into problems with this limitation.
The text was updated successfully, but these errors were encountered:
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.
Original bug ID: 7495
Reporter: @mmottl
Assigned to: @damiendoligez
Status: acknowledged (set by @mshinwell on 2017-03-07T12:33:34Z)
Resolution: open
Priority: normal
Severity: minor
Version: 4.04.0
Category: runtime system and C interface
Monitored by: @mshinwell @mmottl
Bug description
Consider the following code:
This code will let memory consumption quickly go into the GB range. A comparable implementation using float arrays will stay stable in the low MB range:
I remember that this is a long-standing problem, probably the same as #4616, and likely affects custom block allocation in general. Not sure whether it's already tracked in another still active issue. Since the GC will likely undergo significant changes in the near future due to attempts to parallelize it, I think this issue should remain on people's mind. Some practical numerical code can run into problems with this limitation.
The text was updated successfully, but these errors were encountered: