Rudy Velthuis

I use: Inkscape, Libre office, Gimp, Blender, Audacity, Atom, etc. I know how to use these programs, but don't have the expertise to improve them. And the soures for these things are vast. It would take days to acquire some familiarity with them. Then I would have to find out, if I could, how to improve things. Very unlikely scenario.

Sure. And yet I think well but manually written assembler beats every compiler, despite the often used "a good compiler ... etc.". There are indeed a number of good, optimizing and popular compilers. I don't think they are plenty.

I would want the ability to do things manually (by giving the record a destructor -- if I don't write a destructor, then the runtime will do its usual thing) and forego the rather inefficient type info queries for every field. I know which items need finalization and which type they are and can therefore do it much more efficiently than something like FinalizeRecord, which has to find these things out at runtime. The ideal situation would be, of course, if the compiler automatically added (wrote) such a destructor for us, using the knowledge it has about the types in the record at compile time, instead of simply compiling in a function like FinalizeRecord and type info. But what I have seen (and which was removed again) already showed a lot of promise.

We have slow RTL routines that are mainly slow because they have to read all that type info before they can do what they are supposed to do. Sure, some of it can be improved, but that is not of much help. The new ctors etc. can work as I said, and I have seen them work that way (no need for type info whatsoever) before they were removed again. Again, if done right, they will not have to rely on type info anymore and then the door is open for many improvements that do not need patching the runtime or the compiler. I am personally against patching anything, as there often is no need. But I am all for better ways to handle records and arrays without type info. And yes, the constructor of each record in a large array must be called, if there is such a constructor. That is the same as in C++, and there it works remarkably well, especially if this can be inlined and if the call can be eliminated if it is empty. And indeed, an optimized version of InitializeArray etc. could simply do the entire array at once (e.g. nil it out). That should be enhanceable too, sure. But that is InitializeArray, not InitializeRecord. But I don't quite understand: "regardless the fact if the fields are even filled with something". Do you mean "evenly", i.e. do you mean a record that has, for instance, exactly two or more string fields and can therefore be cleared much more efficiently than the current way of looping through the entire type info for each field?

Of course I have. But first I don't like the old-style IDE (Lazarus) and FPC is not nearly on the same level as Delphi, despite Delphi's bugs and other shortcomings. And yes, it is open source, but I am not inclined to get acquainted with the complete compiler/linker/code generator source code so I may be able to tweak the output. The argument "it is open source so you can change it if you like" only works for rather trivial projects, IMO. I use a lot of open source, but I don't want to tweak any of it by browsing though the usually vast number of hard-to-read source files. And my level of expertise is not good enough to be of any help either.

Well, no compiler without a language. If I don't like the language, it is very unlikely I will gladly use a compiler for it.

Yes, we could perhaps write a better _InitializeArray, _FinalizeArray and _CopyRecord and patch these, but that is not good enough, We don't want these to be called at all, no matter how good they are. Because they still need to loop through a lot of type info to find out which parts of a record must be treated how. That is why the new constructors/destructors etc. would be so cool: you can do your own initialization, finalization and copying manually, i.e. your code knows what to do with which field and doesn't have tediously to loop through type info. That should make records a lot faster (if done right). You could even do your own reference counted types and your own dynarrays and what not. You could have a dynarray for integers only, completely with refcounts, but it would not have to initialize much, nor would it have to finalize the integers at all, etc. It would not be dependent on type info. And it would still be like the dynarrays in Delphi, just faster and with methods.

It is very hard to find good compilers I like. I can get along with C and C++, but I don't like them. I love Delphi, but it certainly needs better optimization (and fewer bugs). I like assembler too, because it allows me to do almost everything I want. If I want optimization, it is my responsibility. If I have bugs, it was me (well, or the libraries I use).

That's a commonplace, but I am not convinced. A good assembler programmer can produce better code than any optimizing compiler.

OK, so you are one of the few exceptions for whom performance is *always* critical. Most of the code I see is mainly non-critical, but may have some critical parts. I generally resort to assembler (if possible, i.e. on Windows, 32 bit or 64 bit target), although I always try to have a PUREPASCAL backup and I optimize that as much as I can. And, as I said, it may well be that some of these optimizations were rolled back. I know I have seen some and I was quite surprised to see them.

That may well be. I doubt that optimizations often make a difference in the runtime of a program, unless you are really running very processor-intensive code. But even then, the algorithms used are far more important than an optimized runtime. But sometimes, you really wish you could have better optimized code. I also wish we could have, unlike in any other programming languages (except assembler) access to overflow, zero, negative or carry flags. It could speed up a lot of (my PUREPASCAL) code. And if we could have the new default constructors/automatic destructors/assignment operators/copy constructors, etc. for records, much of the code that currently requires type info to initialize, finalize and copy a record could be improved manually and that would really be a Good Thing. Much of the code that I write, involving BigIntegers and BigDecimals, but also other code, could be optimized a lot. FWIW, it is possible that the optimizations I saw were rolled back too, together with the code for the above constructors etc. FWIW, there were some braindead constructs there too (and some idiotic code duplication or unnecessary nilling of local variables, etc., etc.) and the code was far from ready to be released. A delayed release would not have solved that either. ISTM the problems were much larger than originally estimated.

I don't remember whre, but I have seen some improvements in code generation, especially in the 64 bit compiler, when I was searching for some bugs in the code generator during the FT. I did not write them down. I guess I should have. FWIW, the really optimized compilers are the Clang C++ compilers. In debug mode, their code is terribly clumsy and ugly and slow. In release mode, it is blazingly fast. It is just very hard to put a breakpoint in the release mode code and debug the executable. The few times I managed (by chance), I saw highly optimized code.

That is something that needs to be addressed too, certainly, but it would not be on the top of my list.

For those who write their own generics, you have two ways to do this: the naive but generic way, which can still result in code bloat, and the System.Generics.Collections way, which goes against almost every prinicple of generics, i.e. that you don't have to repeat yourself ad infinitum. I wrote about that already: The current state of generics What they did with the new intrinsics solves part of the problem for their own classes, but it certainly doesn't solve the problem for us who would like to write generics without having to worry about code bloat and without having to do a lot of "copy-and-paste generics". If they can make the compiler select different pieces of code depending on these new intrinsics, they can just as well make the compiler generate such code without us having to worry about it. That is more work, but that is how it should be. In the meantime, they should also finally fix Error Insight (not only for the new inlined vars) and make the new themed IDE a lot more responsive.

That was even the case in the old style non-enhanced generics. The locality of critical code was the same, it was just repeated too often in different parts of the program. I don't expect a big speed difference due to that (but there may have been speed differences due to better optimization in the compilers and especially in the runtime).

In the latest versions, the bloat for the collections in System.Generics.Collections has been battled successfully (using the newly introduced intrinsics, which greatly reduce the amount of generated code), but at the cost of a lot of source code duplication (but note that most of that is eliminated during code generation), which is actually what generics are supposed to overcome. Code was never slow because of the bloat, the generated code in total was just larger than necessary. So no, there is not much bloat anymore (not more than if you had written the code for each type manually, re-using where possible), but there is a lot of copy-paste generics again.

Indeed. And full specs are often not available. You can always forget certain corner cases. Dijkstra was right: you can only test for the presence, but never for the absence of deficiencies.

A nice example of where people have to rely on the implementation (and no, this is not a Good Thing[tm]) is this Stack Overflow question and the answer: > Use a TreeSet, which by default uses compareTo(), unlike a HashSet, which uses equals() and hashCode(). You'll have to know that while BigDecimals with values 0.1 and 0.100 compareTo() as the same value (return value 0), but equal() (which tests for equal internal representation) returns false.

Aw come one, you got that somewhere else. <g> Ah. here it is: " There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." -- C.A.R. Hoare And: "Program testing can be used to show the presence of bugs, but never to show their absence!" -- Edsger W. Dijkstra. After all, I still have this quotes file I use for XanaNews. <g>

Obviously testing thread-related code is hard too.

On the contrary: it is not preferred not to rely on implementation details. Implementation details are things you know about how a piece of software currently works, but which are not documented (although sometimes they are) and/or which may change in later versions. Do not rely on such details. Rather rely on public interfaces and documented traits of the software. The latter of your examples is an implementation detail, i.e. that internally, the virtual tree uses Node.States. It may one day have a different way to denote that a node is expanded.

They are all in different directories (if you need the units) or have different suffixes (if you need packages). No big deal. Never had any problems with that.

Different posts were posted to different kinds of media (here, S.O.) on different servers. That is not cross-posting.

Yes, C or C++ header translations (altough I would prefer integers and masks for those). For plain Delphi code they don't make a lot of sense.

I have no idea what you mean, but I do think that this discussion is fruitless. You obviously have a different POV than I have.