David Heffernan

3 minutes ago, Lars Fosdal said:

I wonder if anyone has tried to train an LLM on Assembly code generation to see if it could improve the current optimization patterns?

(PDF) Application of artificial intelligence in compiler design (researchgate.net)

 (ijresm.com)

10 minutes ago, David Schwartz said:

However, I seriously doubt they're using Delphi to do so.

Yeah, you are wrong. Such people exist. I am one.

10 minutes ago, David Schwartz said:

Likewise, I'm confident that there are plenty of problems that can be written without pointers and bit-whacking, but if you want to drop down to that level, then the program will definitely run much faster. 

Not necessarily. No reason why pointer arithmetic should be faster than, for example, plain indexing of arrays.

11 minutes ago, David Schwartz said:

And if you go all the way down to Assembly language, they'll run even faster.

Again, good compilers are often better than humans.

13 minutes ago, David Schwartz said:

Sure, pointers are heavily used in the RTL and common libs that I think SHOULD be highly optimized. But the people responsible for them are the library vendors, not end-users.

I don't think pointers are used in the RTL especially more than other libraries, and I don't think pointers are used there fore for optimisation and performance.

As far as this whole memory safety debate goes, you can't exclude the RTL from it. That code executes in the code that is subject to attack.

On 4/4/2024 at 3:39 PM, msd said:

therefore, I need someone with expertise in Delphi to convert those libraries to native Delphi Pascal files

I'm not quite sure what you are saying here? Are you looking to hire somebody?

6 hours ago, pyscripter said:

There was no mention of it in today's seminar.

This was in fact mentioned

I guess they will be able to say that the numbers of bugs reported is going down and claim that indicates quality has improved. 

Split views which other IDEs have had for years. And bug fixes. But still no way to report bugs. 

Does this seem like value for money to anybody? 

6 minutes ago, JonRobertson said:

Such as weird UI issues that do not occur in 32-bit but do occur in 64-bit, which I've encountered more than once

Unlucky for you. I've so far never encountered such a problem.

The type of thing that forces me to debug 64 bit is when it's my DLL hosted in a 64 bit process, and I don't have a 32 bit version of the host.

I think all in all, it's clear that the current in-process design is the right one

20 hours ago, A.M. Hoornweg said:

If you'd ask me to attempt a thing like that, I'd first look for a suitable bidirectional RPC framework. Something having capabilities like COM.  COM was used by IDE's such as Visual Basic to host (in-process) VBX controls but it works across processes as well. The "helper processes" would only need to contain the designtime part of the components, at runtime they do nothing.  Such an approach would move the design time components out of the address space of the IDE.  Also, the "bitness" of the helper processes and the IDE would be independent from each other.

How are you going to have the components paint themselves on the design surface?

14 hours ago, JonRobertson said:

I still have problems using the "integrated" (sort of) debugger with Win64 projects.

Win64 debugger is known to be terrible. Perhaps slightly less so with more recent versions. I always debug 32 bit if at all possible. But sometimes you have a scenario where that's not possible. Unlucky if you do.

3 hours ago, A.M. Hoornweg said:

My preference would be to have the component packages in separate helper processes.

 

I can imagine this working fine for non visual components but what about components that paint themselves on the design surface? Cross process window hierarchies are basically untenable. 

13 hours ago, dennis12 said:

Delphi memory manager is very fast and for small block allocation it has some parallelism built in.

Automatic stack allocation is faster than all heap allocators, and has no thread contention. And Delphi's current heap allocator is known not to be scalable.

I've measured this in a real world setting. Avoiding heap allocations when converting numbers (integer and real) to text makes a huge performance difference when creating files, e.g. XML, JSON, YAML. Even when single threaded. When multi-threading the impact is even greater, if using the default heap allocator. I personally use isolated per thread heaps to reduce contention. This doesn't eliminate it because every allocation/deallocation that requires a call to VirtualAlloc and friends has contention.

3 hours ago, Berocoder said:

I assume those Delphi developers that using a Mac M1, M2 or M3 would be happy if Embarcadero would recompile Delphi IDE and compiler to Windows ARM.
What is the potential problem with that ?

I mean, how hard could it be????

You suspect encoding is an issue but I can't see in your post any discussion of encoding. 

5 minutes ago, darnocian said:

 

Ok. I was just hoping for some sort of example, as the SameValue/isZero is a generalised approach. 

 

So back to the original post, I guess we can just take it that there are some issues with the new version of the compiler, and will need to log some issues with QP once it is back again.

Sometimes you do compare up to tolerance. Sometimes that's the right way to do it. But you need to know how to choose the tolerance. 

And it's definitely wrong to say that one must never compare exactly. Sometimes you can. Although delphi rtl works against you. For instance you'd hope to be able to convert floats to text, and back, and get the same value. In Delphi using the rtl functions this isn't always the case. Embarcadero have known this for more than a decade and not done anything yet. 

I just don't think they have the resources required to prioritise this given all their other commitments. 

21 minutes ago, darnocian said:

I'm still interested to know more about any alternatives to using epsilon for comparison. I've only seen subtle variations on the same theme, and always keen to learn something new.

It depends on what you are comparing, what algorithms are involved etc. 

3 hours ago, Attila Kovacs said:

I read something in so from you but I can't find it, it was about the whole rtl float handling is rubbish or something like that. Not sure about the details.

Well, that's true. Lots of thread safety issues with how it handles floating point control status. But that's not that same as having a math lib. 

1 hour ago, Attila Kovacs said:

You wanted to make your math lib available for the public, back in the days. Still waiting 😛

I don't have a math lib that is publishable. I've never wanted to have or do such a thing. You must be mis-remembering.

7 hours ago, darnocian said:

The rationale for it is when it comes to rounding due to the way the float is represented with limited bits... there will be to mismatches. You may be lucky, and comparison may work, but the epsilon comparison approach is a failsafe method to cater for rounding issues in the process of various calculations.

I know how floating point math works, it's been what I've done for a living for the past 30 years. 

Using arbitrary epsilon values is not failsafe and relies on luck. 

10 minutes ago, Uwe Raabe said:

The default values currently used actually cover a common beginner's mistake assuming that floats can be compared for exact equality.

Floats can be compared for exact equality, in plenty of circumstances. The beginner mistake is to use some epsilon value without any sound rationale for it.

10 minutes ago, Uwe Raabe said:

Usually the IsZero implementation works pretty good for the majority of the cases

Usually, and works pretty good, and for the majority of cases doesn't sound great with my numerical programming head on.

51 minutes ago, darnocian said:

What do you mean by useless? Just not liking the specific implementation? 

This entire approach of applying some arbitrary epsilon is rubbish. I can't imagine any scenarios where they'd be useful and I've only ever seen them used inappropriately.

The best way to deal with this is never to call any of these functions in the first place, they are all useless

7 hours ago, PiedSoftware said:

Yes, David, I agree. I would like them to fill that out: everything that is logically able to be evaluated at compile time should be assignable to a constant.

We'd all like that. Prospects are not good for it happening.

There's all sorts of things that Delphi should allow as constants, but that's a long known area of significant weakness in the language. 

2 hours ago, Rollo62 said:

Can the memory safety of RadStudio C++ safely assumed to be more improved than standard C++, because it's close relation to its sibling Delphi within the same package?

No