-
Content Count
3710 -
Joined
-
Last visited
-
Days Won
185
Everything posted by David Heffernan
-
Parallel for 32 vrs 64bits
David Heffernan replied to pyscripter's topic in RTL and Delphi Object Pascal
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); -
RTTI info for TBytes using runtime packages
David Heffernan replied to Wagner Landgraf's topic in RTL and Delphi Object Pascal
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. -
How to remember units and classes, where is what?
David Heffernan replied to Mike Torrettinni's topic in Algorithms, Data Structures and Class Design
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. -
FastMM5 now released by Pierre le Riche (small background story)
David Heffernan replied to Günther Schoch's topic in Delphi Third-Party
Impossible to know without benchmarking. Depends on what your application spends its time doing. -
Mask floating point exceptions, probably
-
Experience/opinions on FastMM5
David Heffernan replied to Leif Uneus's topic in RTL and Delphi Object Pascal
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. -
FastMM5 now released by Pierre le Riche (small background story)
David Heffernan replied to Günther Schoch's topic in Delphi Third-Party
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.
-
Experience/opinions on FastMM5
David Heffernan replied to Leif Uneus's topic in RTL and Delphi Object Pascal
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? -
Experience/opinions on FastMM5
David Heffernan replied to Leif Uneus's topic in RTL and Delphi Object Pascal
Wrong. They are restricted by the GPL. -
Experience/opinions on FastMM5
David Heffernan replied to Leif Uneus's topic in RTL and Delphi Object Pascal
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. -
Experience/opinions on FastMM5
David Heffernan replied to Leif Uneus's topic in RTL and Delphi Object Pascal
Don't use the hammer then. Make your own. Your choice. -
Experience/opinions on FastMM5
David Heffernan replied to Leif Uneus's topic in RTL and Delphi Object Pascal
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. -
Experience/opinions on FastMM5
David Heffernan replied to Leif Uneus's topic in RTL and Delphi Object Pascal
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. -
Experience/opinions on FastMM5
David Heffernan replied to Leif Uneus's topic in RTL and Delphi Object Pascal
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. -
Experience/opinions on FastMM5
David Heffernan replied to Leif Uneus's topic in RTL and Delphi Object Pascal
Fine if you are multiprocessing, but not if multithreading. -
Thread programming without sleep or WaitFor events
David Heffernan replied to turkverisoft's topic in Delphi IDE and APIs
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.
-
Experience/opinions on FastMM5
David Heffernan replied to Leif Uneus's topic in RTL and Delphi Object Pascal
Would be interested to know whether NUMA memory is handled well. -
Thread programming without sleep or WaitFor events
David Heffernan replied to turkverisoft's topic in Delphi IDE and APIs
Regarding timers and energy use: https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/ -
Thread programming without sleep or WaitFor events
David Heffernan replied to turkverisoft's topic in Delphi IDE and APIs
You asked the same question on SO: https://stackoverflow.com/questions/61505887/thread-programming-without-sleep-or-waitfor-events It was closed there because it lacked focus. You seem to be wanting advice to a level of detail that far outstrips the level of detail used to specify your problem, and your current solution. In my view you are unlikely to be anything much out of a question asked the way you did. I recommend that you step back and provide a lot more detail and background. That will give you more hope of getting relevant advice. -
https://stackoverflow.com/q/19054789/505088