David Heffernan

Why do you feel that there might be a problem? The rules for identifiers are well documented. These all meet the rules.

No. That's wrong. In fact sin is quicker under x64 than under x86. Even though sin (and other trig) is implemented in hardware in the x87 unit, and in Pascal in x64 (because the SSE2 unit does not have built in trig).

The issue is that x64 trig functions are very slow for very large values. Nobody actually wants to know sin for 99999999/pi radians. Put in sensible values for the argument to sin and it looks more reasonable. For instance try using T:=Sin(i/99999999);

Essentially what the original post tells you is that these two types are distinct. Since they are declared in the rtl package, at least one of your modules is not linking to the rtl as a runtime package.

The best way is that you understand your design well in the first place. My reading of your various posts is that a lot of the time you are developing your code by following methodologies used like a recipe. I suspect that with a deeper understanding of why these methodologies were being used then you wouldn't find your code alien when you encounter it.

Impossible to know without benchmarking. Depends on what your application spends its time doing.

Mask floating point exceptions, probably

Another way to improve performance is to design the code to minimise heap allocations. The best way to optimise a block of code is not to bypass it.

It's pointless to say that one memory manager is n times faster than another because usage varies so much. One thing that is surely true is that different applications have different needs. I'm personally pretty sceptical that one single memory manager can perform optimally in a wide range of usage scenarios. Nothing wrong with choosing the MM that best fits each application.

Oh. This again. Surely your users can just make the the icon appear always if they want to. Perhaps they don't want to.....

There are lots of bugs in the IDE that could explain this. But this could equally be caused by bugs in design time packages or plugins that you have installed. It won't be caused by the code that you are compiling in the IDE.

I don't understand the problem. I think that if you want some input you'd need to make it more clear to us what your code is doing and how it fails to achieve your goals.

You could just ignore the error. Is it causing any trouble.

Use a different memory manager then. You don't have rights to other people's work. Do I have rights to your work? What on earth are you smoking?

Wrong. They are restricted by the GPL.

That's not really the point. The developers of any code own it. They get to choose how they licence it. They have many options. Basic decency says we respect their choices. I'm confident that every person who is critical of somebody else's choice of licence would flat out reject it if anybody told them how to licence their own software.

Don't use the hammer then. Make your own. Your choice.

Yeah, that makes a lot of sense. I could do this, but I'd probably need a little guidance on how to integrate fastmm5 with my program, making sure it was configured properly, and used the right branch.

I would expect so, but I don't know for sure. I do know that when using HeapCreate / HeapAlloc this is true, but that's no use to you. I do have a NUMA machine to hand and would be happy to run some tests on it if that would be useful for you.

My question was based on my own experience running multithreaded floating point software on NUMA machines, an issue that was live for me maybe three years ago. My problem was that most memory managers allocate out of a shared pool, but that cross node memory access is much more expensive than within node memory access. I didn't find any Delphi memory managers that were both robust and able to allocate memory local to the node on which the calling thread was executing. IIRC, allocators such as that of TBB and others used in the C++ world were able to do this. My application is a little different to more mainstream Delphi applications however. I understand that fastmm targets usage with frequent allocation of relatively small objects. In my application I preallocate wherever possible and avoid allocation in any hotspot. So my goal could just be boiled down to achieving affinity to the local node. In the end I wrote my own memory allocator on top of HeapCreate / HeapAlloc etc. The strategy is the each NUMA node has its own private heap (allocated by a call to HeapCreate). Each allocation is performed on the heap associated with the calling thread's node. I'm not in any way suggesting that such a simple strategy would be appropriate for fastmm. The interesting thing that I observed is that raw heap allocation / deallocation performance was never a problem for my app, because of the efforts we took to avoid allocation in hotspots. Likewise for thread contention, for the same reasons. The issue was that memory access speeds in my app is a key performance factor. And cross node access has dire performance.

Fine if you are multiprocessing, but not if multithreading.

Unlucky for you. We've stopped supporting Windows 7, after all MS doesn't anymore.

BPL not corrupted. Just a defect in some code that runs inside the IDE.

Would be interested to know whether NUMA memory is handled well.

Regarding timers and energy use: https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/