Re: slow runtime

2010-09-11 Thread bearophile
Jonathan M Davis: > In any case, if you're looking to avoid GC collection cycles, it sounds like > std.gc.disable() and std.gc.enable() will help. But remember that that will > increase the odds that it will have to allocate more memory from the OS, > which > isn't cheap either. It's almost ce

Re: slow runtime

2010-09-10 Thread Andrej Mitrovic
No worries, I'm just investigating. I don't need real-time performance any time soon. :) I have seen a pluggable .NET system that has to run in real-time. If that's possible in .net, I'm sure it will be possible in D (if it isn't already). Thanks for all your input! On Sat, Sep 11, 2010 at 5:23

Re: slow runtime

2010-09-10 Thread Jonathan M Davis
On Friday 10 September 2010 19:40:10 Andrej Mitrovic wrote: > What about gc.disable() and gc.enable() ? If I'm sure that I won't > allocate anything within a section of code and I have to guarantee > realtime performance, then I could disable the gc temporarily. > Although this is not exactly what

Re: slow runtime

2010-09-10 Thread Andrej Mitrovic
This page might need to be updated soon: http://www.digitalmars.com/d/2.0/memory.html It refers to custom allocators, overloading new and delete, and using scope for stack allocation. On Sat, Sep 11, 2010 at 4:40 AM, Andrej Mitrovic wrote: > What about gc.disable() and gc.enable() ? If I'm sure

Re: slow runtime

2010-09-10 Thread Andrej Mitrovic
What about gc.disable() and gc.enable() ? If I'm sure that I won't allocate anything within a section of code and I have to guarantee realtime performance, then I could disable the gc temporarily. Although this is not exactly what it states in the section on memory management: "Call std.gc.disable

Re: slow runtime

2010-09-10 Thread Jonathan M Davis
On Friday 10 September 2010 17:36:06 Andrej Mitrovic wrote: > This is why I'm happy to see some people (Leandro in particular) are > already working on different GC designs for D. :) > > So to evade the GC's pauses as much as possible, one would stick with > using structs or preallocate all needed

Re: slow runtime

2010-09-10 Thread Andrej Mitrovic
This is why I'm happy to see some people (Leandro in particular) are already working on different GC designs for D. :) So to evade the GC's pauses as much as possible, one would stick with using structs or preallocate all needed data before a critical section? I'll have to get more into that event

Re: slow runtime

2010-09-10 Thread Jonathan M Davis
On Friday 10 September 2010 09:44:10 bearophile wrote: > Andrej Mitrovic: > > So does that mean the GC doesn't make any pauses, unless it requires more > > memory from the OS? > > When you ask memory to the GC, it may perform collections, so it performs > some computations, even if no new memory g

Re: slow runtime

2010-09-10 Thread bearophile
Andrej Mitrovic: > So does that mean the GC doesn't make any pauses, unless it requires more > memory from the OS? When you ask memory to the GC, it may perform collections, so it performs some computations, even if no new memory gets asked to the OS. Bye, bearophile

Re: slow runtime

2010-09-10 Thread Andrej Mitrovic
Let's see if I got this right. The GC asks for some memory from the OS, and keeps it in a pool. Then when we have to allocate an array, we take some memory from the GC pool. And when we no longer need the array, the memory gets put back into the pool to be reused. So does that mean the GC doesn'

Re: slow runtime

2010-09-10 Thread Pelle
On 09/10/2010 10:17 AM, Jonathan M Davis wrote: On Friday 10 September 2010 00:50:32 bearophile wrote: Jonathan M Davis: Aren't they _always_ on the heap? void main() { int[10] a; int[] b = a[]; } Bye, bearophile Ah, good point. When you have a slice of a static array as opposed

Re: slow runtime

2010-09-10 Thread Jonathan M Davis
On Friday 10 September 2010 00:50:32 bearophile wrote: > Jonathan M Davis: > > Aren't they _always_ on the heap? > > void main() { > int[10] a; > int[] b = a[]; > } > > Bye, > bearophile Ah, good point. When you have a slice of a static array as opposed to a dynamic arra allocated with

Re: slow runtime

2010-09-10 Thread bearophile
Jonathan M Davis: > Aren't they _always_ on the heap? void main() { int[10] a; int[] b = a[]; } Bye, bearophile

Re: slow runtime

2010-09-10 Thread Jonathan M Davis
On Thursday 09 September 2010 23:23:45 bearophile wrote: > Jonathan M Davis: > > Now, dynamic arrays live on the stack, even if their references don't, > > Dynamic arrays are generally on the heap. > > Bye, > bearophile Aren't they _always_ on the heap? Their references are obviously on the stac

Re: slow runtime

2010-09-09 Thread bearophile
Jonathan M Davis: > Now, dynamic arrays live on the stack, even if their references don't, Dynamic arrays are generally on the heap. Bye, bearophile

Re: slow runtime

2010-09-09 Thread Jonathan M Davis
On Thursday 09 September 2010 20:54:15 Dr. Smith wrote: > Jonathan, thank you for the quick response. I made some changes as you > suggested and got much more speed. For some code that I'd like to convert > to D, I am exploring the pros and cons of constructing a class library > (versus a C like f

Re: slow runtime

2010-09-09 Thread Jonathan M Davis
On Thursday 09 September 2010 20:17:23 Andrej Mitrovic wrote: > Related: Do stack variables get freed on exit or do they just get marked as > unused by the GC? Because I'm not seeing any memory increase over time. I > guess I have to read more about how allocation works. :p > > Jonathan M Davis Wr

Re: slow runtime

2010-09-09 Thread Dr. Smith
Jonathan, thank you for the quick response. I made some changes as you suggested and got much more speed. For some code that I'd like to convert to D, I am exploring the pros and cons of constructing a class library (versus a C like function library). My code here is just part of that exploration

Re: slow runtime

2010-09-09 Thread Jonathan M Davis
On Thursday 09 September 2010 19:40:47 Dr. Smith wrote: > The class code below runs terribly slow. Conversely, when converted into a > function (albeit returning only one value), it runs fast. Any insights > into this or suggestions to get a function to return multiple types at > once? > > ...li

Re: slow runtime

2010-09-09 Thread Andrej Mitrovic
Related: Do stack variables get freed on exit or do they just get marked as unused by the GC? Because I'm not seeing any memory increase over time. I guess I have to read more about how allocation works. :p Jonathan M Davis Wrote: _every time_ that you use hit or > hot in main(), you're callin

Re: slow runtime

2010-09-09 Thread Jonathan M Davis
On Thursday 09 September 2010 19:40:47 Dr. Smith wrote: > The class code below runs terribly slow. Conversely, when converted into a > function (albeit returning only one value), it runs fast. Any insights > into this or suggestions to get a function to return multiple types at > once? > > ...li

slow runtime

2010-09-09 Thread Dr. Smith
The class code below runs terribly slow. Conversely, when converted into a function (albeit returning only one value), it runs fast. Any insights into this or suggestions to get a function to return multiple types at once? ...library code... module testlib; import std.stdio, std.string; class