It's not possible to create a generic "list of array" that behave almost like a list, with a chunk with a nice size (4KB ?) 2014-07-24 18:44 GMT+02:00 Fabrice Le Fessant : > Well, it is hard to enumerate. The basic idea is to find, for each data > structure, the best trade-off between efficient operations and space > occupation. The simplest example is to decide between using lists or > arrays. Arrays use less space (unless you use hash-consing or you share the > end of the lists), but if you don't know the final size you need, you will > finish either pre-allocating longer arrays than you need, or re-allocating > arrays too often, or switching between lists and arrays... In the end, it > really depends on what an application does. > > There are also other tricks such as changing the tag of a block to avoid > scanning, but I wouldn't advise to use it unless you really know what you > are doing... > > --Fabrice > > > On Thu, Jul 24, 2014 at 5:39 PM, Malcolm Matalka > wrote: > >> Cool, what sort of tricks can you do to reduce the number of blocks? >> Den 24 jul 2014 17:36 skrev "Fabrice Le Fessant" < >> Fabrice.Le_fessant@inria.fr>: >> >> Note that the cost of the GC does not automatically depends on the size >>> of RAM. In many networking servers, memory is filled with strings, caching >>> files on disk or content to be sent on the network. Such cases make OCaml >>> GC happy, since it does not have to manipulate many objects, and it won't >>> scan strings for pointers within them. There are also other tricks to >>> improve the GC behavior: you might want to change the data representation >>> to decrease the number of blocks in the heap, I used to do it a lot when >>> doing computations on millions of entries that would not otherwise stay in >>> memory. >>> >>> --Fabrice >>> >>> >>> On Thu, Jul 24, 2014 at 8:58 AM, Nicolas Boulay >>> wrote: >>> >>>> What about server that use ~60GB of RAM ? Todays server are sold with >>>> 32 to 256 GB of RAM and lot of cpu core. >>>> Maybe in such extreme cases, offloading the major collection of the GC >>>> could reduce latency a lot ? >>>> >>>> >>>> 2014-07-24 2:05 GMT+02:00 John F. Carr : >>>> >>>> >>>>> Most programs spend a minority of their time in garbage collection. >>>>> Even if the new GC thread did not slow down the main program, >>>>> possible speedup would be less than 2x, probably well under 50%. >>>>> >>>>> For technical reasons, offloading major collections in OCaml is easier >>>>> than offloading minor collections, so the potential benefit is less. >>>>> >>>>> > extremely clueless question warning, both generally technically but >>>>> > also vis-a-vie ocaml specifically: >>>>> > >>>>> > so even if ocaml can't so easily be made to support multiple threads >>>>> > of ocaml code, could the gc be moved off to another thread? so that >>>>> it >>>>> > could run on another core. would that be of any benefit? >>>>> >>>>> -- >>>>> Caml-list mailing list. Subscription management and archives: >>>>> https://sympa.inria.fr/sympa/arc/caml-list >>>>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >>>>> Bug reports: http://caml.inria.fr/bin/caml-bugs >>>>> >>>> >>>> >>> >>> >>> -- >>> Fabrice LE FESSANT >>> Chercheur en Informatique >>> INRIA Paris Rocquencourt -- OCamlPro >>> Programming Languages and Distributed Systems >>> >> > > > -- > Fabrice LE FESSANT > Chercheur en Informatique > INRIA Paris Rocquencourt -- OCamlPro > Programming Languages and Distributed Systems >