The execrable existing implementation was scrapped, and the new one uses Windows HeapAlloc().

http://ftp.digitalmars.com/snn.lib

This is for testing porpoises, and of course for those that Feel Da Need For Speed.

On 8/3/2013 2:55 PM, Walter Bright wrote:
> Feel Da Need For Speed.

So much better than:

 Feel Da Need For Reduced Elapsed Time

:-)

Am 03.08.2013 23:55, schrieb Walter Bright:
> The execrable existing implementation was scrapped, and the new one uses Windows
> HeapAlloc().
>
> http://ftp.digitalmars.com/snn.lib
>
> This is for testing porpoises, and of course for those that Feel Da Need For Speed.
>

ever tested nedmalloc (http://www.nedprod.com/programs/portable/nedmalloc/) or other malloc allocators?

On 8/3/2013 11:07 PM, dennis luehring wrote:
> ever tested nedmalloc (http://www.nedprod.com/programs/portable/nedmalloc/) or
> other malloc allocators?

No, I haven't.

On Sunday, 4 August 2013 at 06:07:54 UTC, dennis luehring wrote:
> ever tested nedmalloc (http://www.nedprod.com/programs/portable/nedmalloc/) or other malloc allocators?

"Windows 7, Linux 3.x, FreeBSD 8, Mac OS X 10.6 all contain state-of-the-art allocators and no third party allocator is likely to significantly improve on them in real world results."

So there may be minimal returns from incorporating nedmalloc on modern OS's ... ?

On 8/4/2013 12:19 AM, Joseph Rushton Wakeling wrote:
> On Sunday, 4 August 2013 at 06:07:54 UTC, dennis luehring wrote:
>> ever tested nedmalloc (http://www.nedprod.com/programs/portable/nedmalloc/) or
>> other malloc allocators?
>
> "Windows 7, Linux 3.x, FreeBSD 8, Mac OS X 10.6 all contain state-of-the-art
> allocators and no third party allocator is likely to significantly improve on
> them in real world results."
>
> So there may be minimal returns from incorporating nedmalloc on modern OS's ... ?

As I wrote earlier, Microsoft has enormous incentive to make HeapXXXX as fast as possible, as it will pay dividends for every Microsoft software product and software designed for Windows. I'm sure the engineers there know all about the various strategies available on the intarnets. Why not take advantage of their work?

Am 04.08.2013 09:35, schrieb Walter Bright:
> On 8/4/2013 12:19 AM, Joseph Rushton Wakeling wrote:
>> On Sunday, 4 August 2013 at 06:07:54 UTC, dennis luehring wrote:
>>> ever tested nedmalloc (http://www.nedprod.com/programs/portable/nedmalloc/) or
>>> other malloc allocators?
>>
>> "Windows 7, Linux 3.x, FreeBSD 8, Mac OS X 10.6 all contain state-of-the-art
>> allocators and no third party allocator is likely to significantly improve on
>> them in real world results."
>>
>> So there may be minimal returns from incorporating nedmalloc on modern OS's ... ?
>
> As I wrote earlier, Microsoft has enormous incentive to make HeapXXXX as fast as
> possible, as it will pay dividends for every Microsoft software product and
> software designed for Windows. I'm sure the engineers there know all about the
> various strategies available on the intarnets. Why not take advantage of their work?

HeapAlloc is a forwarder to RtlHeapAlloc and C++ new does call RtlHeapAlloc directly - would it be better to use this kernel32 api directly? (maybe if used in druntime to reduce dll dependencies)

On 8/4/2013 12:53 AM, dennis luehring wrote:
> HeapAlloc is a forwarder to RtlHeapAlloc and C++ new does call RtlHeapAlloc
> directly - would it be better to use this kernel32 api directly? (maybe if used
> in druntime to reduce dll dependencies)
>

I can't find any documentation on RtlHeapAlloc.

04.08.2013 11:53, dennis luehring пишет:
> Am 04.08.2013 09:35, schrieb Walter Bright:
>> On 8/4/2013 12:19 AM, Joseph Rushton Wakeling wrote:
>>> On Sunday, 4 August 2013 at 06:07:54 UTC, dennis luehring wrote:
>>>> ever tested nedmalloc
>>>> (http://www.nedprod.com/programs/portable/nedmalloc/) or
>>>> other malloc allocators?
>>>
>>> "Windows 7, Linux 3.x, FreeBSD 8, Mac OS X 10.6 all contain
>>> state-of-the-art
>>> allocators and no third party allocator is likely to significantly
>>> improve on
>>> them in real world results."
>>>
>>> So there may be minimal returns from incorporating nedmalloc on
>>> modern OS's ... ?
>>
>> As I wrote earlier, Microsoft has enormous incentive to make HeapXXXX
>> as fast as
>> possible, as it will pay dividends for every Microsoft software
>> product and
>> software designed for Windows. I'm sure the engineers there know all
>> about the
>> various strategies available on the intarnets. Why not take advantage
>> of their work?
>
> HeapAlloc is a forwarder to RtlHeapAlloc and C++ new does call
> RtlHeapAlloc directly - would it be better to use this kernel32 api
> directly? (maybe if used in druntime to reduce dll dependencies)
>

Up to Windows XP (at least) KERNEL32's HeapAlloc function is forwarded to RtlAllocateHeap [1] function exported by NTDLL so there is no runtime performance overhead.

There is no RtlHeapAlloc function on my Windows XP and I can't find any information about it on the web. Looks like a Windows 6.x stuff or a mistake in name.

Also note there are tons of errors because of such "slightly different" names. If we are talking about "Heap*" functions:
1. Incorrect "RtlAllocHeap" name here [2].
2. Incorrect "HeapFree" function signature (4-byte BOOL is returned but it is just a wrapper of RtlFreeHeap which returns 1-byte BOOLEAN) (fixed in Windows 6.x).

[1] http://msdn.microsoft.com/en-us/library/windows/hardware/ff552108(v=vs.85).aspx
[2] http://msdn.microsoft.com/ru-ru/magazine/cc301808(en-us).aspx

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

04.08.2013 1:55, Walter Bright пишет:
> The execrable existing implementation was scrapped, and the new one uses
> Windows HeapAlloc().
>
> http://ftp.digitalmars.com/snn.lib
>
> This is for testing porpoises, and of course for those that Feel Da Need
> For Speed.

So I suppose you use `HeapFree` too? Please, be sure you use this Windows API BOOL/BOOLEAN bug workaround:
https://github.com/denis-sh/phobos-additions/blob/e061d1ad282b4793d1c75dfcc20962b99ec842df/unstd/windows/heap.d#L178

-- 
Денис В. Шеломовский
Denis V. Shelomovskij