On 03/26/2011 04:43 AM, Jonathan M Davis wrote:
> I find the responses to this list to be rather interesting. Most of it, I find
> to be of mild interest at best (certainly for the sort of stuff that _I_ do
> anyway), but others find some of them to be very desirable.
>
>> >  List in order from most to least finished:
>> >
>> >  1.  Rational:  A library for handling rational numbers exactly.  Templated
>> >  on integer type, can use BigInts for guaranteed accuracy, or fixed-width
>> >  integers for more speed where the denominator and numerator will be small.
>> >    Completion state:  Mostly finished.  Just need to fix a litte bit rot and
>> >  submit for review.  (Phobos candidate)
> Potentially interesting, but I don't know if I'd ever use it.

That's it: never ever listen to people to know what they /really/ need, really find useful, really appreciate. Many are able to push like crazy for thingies that just look cool (esp at design time), but none of them will actually use for three years. (experienced ;-)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 3/26/2011 4:25 AM, Johan Granberg wrote:
> Definitely some would love it, me among them. This to me feels like the most
> useful. Does your (dsimcha) implementation support spare matrices as well,
> and if not are the api general engough to support them if someone has time
> to implement them. When you say looks like normal matlab does that include
> b=A\x? Regardless any standardization of linear algebra libraries would
> improve on the current state in most languages.

No support for sparse matrices, but the API should have no problem supporting them eventually.  It's all templates.  I'd like to support b=A\x, but D doesn't have a \ operator.  At any rate, it's not much more verbose to do b = solve(A, x).

On 3/18/2011 2:56 AM, Don wrote:
>> 3. TempAlloc: A memory allocator based on a thread-local segmented stack,
>> useful for allocating large temporary buffers in things like numerics
>> code.
>> Also comes with a hash table, hash set and AVL tree optimized for this
>> allocation scheme. The advantages over plain old stack allocation are
>> that
>> it's independent of function calls (meaning you can return pointers to
>> TempAlloc-allocated memory from a function, etc.) and it's segmented,
>> meaning
>> you can allocate huge buffers w/o risking stack overflow. Its main
>> weakness
>> is that this stack is not scanned by the GC, meaning that you can't
>> store the
>> only reference to a GC-allocated piece of memory here. However, in
>> practice
>> large arrays of primitives are an extremely common case in
>> performance-critical code. I find this module immensely useful in
>> dstats and
>> Lars Kyllingstad uses it in SciD. Getting it into Phobos would make it
>> easy
>> for other scientific/numerics code to use it. Completion state:
>> Working and
>> used. Needs a litte cleanup and documentation. (Phobos candidate)
>
> This is #1. Far and away. Belongs in druntime.
> I would use it instantly in BigInt.

This is not up for "official" review yet because std.net.isemail and std.parallelism (and possibly more stuff depending on how we manage the review queue) are ahead of it.  If you want a sneak preview:

Code:

https://github.com/dsimcha/TempAlloc

Docs:

http://cis.jhu.edu/~dsimcha/d/phobos/core_tempalloc.html

I put in a few small, tangentially related memory allocation functions that I've wanted in druntime/Phobos for awhile in this proposal, too. alignedMalloc() and alignedFree() are used by TempAlloc but can be made private if people don't like them.  newVoid() is not used by TempAlloc and might fit better in std.array, but I think it belongs somewhere in Phobos or druntime.

On Sun, 27 Mar 2011 12:09:03 +0900, dsimcha <dsimcha@yahoo.com> wrote:

> On 3/18/2011 2:56 AM, Don wrote:
>>> 3. TempAlloc: A memory allocator based on a thread-local segmented stack,
>>> useful for allocating large temporary buffers in things like numerics
>>> code.
>>> Also comes with a hash table, hash set and AVL tree optimized for this
>>> allocation scheme. The advantages over plain old stack allocation are
>>> that
>>> it's independent of function calls (meaning you can return pointers to
>>> TempAlloc-allocated memory from a function, etc.) and it's segmented,
>>> meaning
>>> you can allocate huge buffers w/o risking stack overflow. Its main
>>> weakness
>>> is that this stack is not scanned by the GC, meaning that you can't
>>> store the
>>> only reference to a GC-allocated piece of memory here. However, in
>>> practice
>>> large arrays of primitives are an extremely common case in
>>> performance-critical code. I find this module immensely useful in
>>> dstats and
>>> Lars Kyllingstad uses it in SciD. Getting it into Phobos would make it
>>> easy
>>> for other scientific/numerics code to use it. Completion state:
>>> Working and
>>> used. Needs a litte cleanup and documentation. (Phobos candidate)
>>
>> This is #1. Far and away. Belongs in druntime.
>> I would use it instantly in BigInt.
>
> This is not up for "official" review yet because std.net.isemail and std.parallelism (and possibly more stuff depending on how we manage the review queue) are ahead of it.  If you want a sneak preview:
>
> Code:
>
> https://github.com/dsimcha/TempAlloc
>
> Docs:
>
> http://cis.jhu.edu/~dsimcha/d/phobos/core_tempalloc.html
>
> I put in a few small, tangentially related memory allocation functions that I've wanted in druntime/Phobos for awhile in this proposal, too. alignedMalloc() and alignedFree() are used by TempAlloc but can be made private if people don't like them.  newVoid() is not used by TempAlloc and might fit better in std.array, but I think it belongs somewhere in Phobos or druntime.

Now, I am thinking of light-weight process for concurrency.
Your TempAlloc(segmented stack) seems to be a good parts for implementing such feature :)


Masahiro

On 3/28/2011 7:38 PM, Masahiro Nakagawa wrote:
> On Sun, 27 Mar 2011 12:09:03 +0900, dsimcha <dsimcha@yahoo.com> wrote:
> 
>> On 3/18/2011 2:56 AM, Don wrote:
>>>> 3. TempAlloc: A memory allocator based on a thread-local segmented
>>>> stack,
>>>> useful for allocating large temporary buffers in things like numerics
>>>> code.
>>>> Also comes with a hash table, hash set and AVL tree optimized for this
>>>> allocation scheme. The advantages over plain old stack allocation are
>>>> that
>>>> it's independent of function calls (meaning you can return pointers to
>>>> TempAlloc-allocated memory from a function, etc.) and it's segmented,
>>>> meaning
>>>> you can allocate huge buffers w/o risking stack overflow. Its main
>>>> weakness
>>>> is that this stack is not scanned by the GC, meaning that you can't
>>>> store the
>>>> only reference to a GC-allocated piece of memory here. However, in
>>>> practice
>>>> large arrays of primitives are an extremely common case in
>>>> performance-critical code. I find this module immensely useful in
>>>> dstats and
>>>> Lars Kyllingstad uses it in SciD. Getting it into Phobos would make it
>>>> easy
>>>> for other scientific/numerics code to use it. Completion state:
>>>> Working and
>>>> used. Needs a litte cleanup and documentation. (Phobos candidate)
>>>
>>> This is #1. Far and away. Belongs in druntime.
>>> I would use it instantly in BigInt.
>>
>> This is not up for "official" review yet because std.net.isemail and std.parallelism (and possibly more stuff depending on how we manage the review queue) are ahead of it. If you want a sneak preview:
>>
>> Code:
>>
>> https://github.com/dsimcha/TempAlloc
>>
>> Docs:
>>
>> http://cis.jhu.edu/~dsimcha/d/phobos/core_tempalloc.html
>>
>> I put in a few small, tangentially related memory allocation functions that I've wanted in druntime/Phobos for awhile in this proposal, too. alignedMalloc() and alignedFree() are used by TempAlloc but can be made private if people don't like them. newVoid() is not used by TempAlloc and might fit better in std.array, but I think it belongs somewhere in Phobos or druntime.
> 
> Now, I am thinking of light-weight process for concurrency.
> Your TempAlloc(segmented stack) seems to be a good parts for
> implementing such feature :)
> 
> 
> Masahiro

I'm not sure what you're suggesting.  I'd definitely need more details to help you in any way.  If it involves fibers, remember that thread-local storage only works with OS threads.  TempAlloc stores its state in thread-local storage.

Other than that, I'm interested in hearing about this.  If there are any enhancements I can add to make what you want to do easier, let me know.