Re: [fpc-devel] "Blank slate" next version of FPC
> The compiler already supports keeping records in registers under the same > conditions, but only up to a certain size (two native registers) and only > using the > same layout as they would have in memory (so no explicit splitting out fields > into separate registers). Using record fields as independent variables if appropriate could be a nice very high-level optimization strategy (AFAIK, GNU C does this easily). With X64 architecture and others that have many registers this seems to make a lot of sense, but it also would allow to allocate seldom used fields ion the stack. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Good timing metric test program?
Well, compiling Lazarus is what I've been doing to test the compiler's speed, and I've got some promising results: https://bugs.freepascal.org/view.php?id=34628#c114453 Though the speed of the runs varies a lot depending on what my system is doing, especially when I switch back and forth between my code and the unmodified trunk, I get about a 15% speed gain in the compiler and a small size saving too, mostly due to overhauled jump optimisations. When it comes to the metric test program, the best comparison I can think of are those fancy benchmark programs used to test graphics cards and spit out a score. Compiling Lazarus is good and all, but you can't easily determine if its compiled code is any more efficient than before, outside of painstakingly studying the disassembly side-by-side with the control case. Saying all that, it might be an incentive to design such a test program that does a number of different operations like multiplying a vector array by a matrix (this would a good test case for vectorisation), generating prime numbers using a Sieve of Eratosthenes (would test array polling) and converting integers into different bases (tests to see how well the compiler can deal with div and mod instructions, especially as, currently, the compiler isn't smart enough to combine the operations if the two appear together, since the DIV instruction returns both the quotient and the remainder simultaneously... even when dividing by a constant, which gets optimised into a multiplication using some trickery with how MUL works on x86 processors, if you try to compute the remainder right afterwards, it will do the multiplication trick again, multiply the resultant quotient by the divisor, and subtract the result from the original number). Of course, lots of those already exist as individual test cases, but I need something more extensive because a lot of optimisations, like those that are designed to decrease the chance of pipeline stalls (I added one in my optimiser overhaul, that turns "mov %reg1,%reg2; mov %reg2,%reg3" to "mov %reg1,%reg2; mov %reg1,%reg3" - I was able to slip it in effectively for free because another optimisation checks for the same arrangement, but only if %reg2 is discarded afterwards, not if it's used again later), are very hard to measure in a small test and need to be a part of an extensive bench test before the benefits start to show. Sometimes I get people asking why I'm bothering trying to find the smallest of savings in size and execution speed - or in my own programming, writing mathematical functions like the aforementioned matrix multiplication in raw assembly language for the same benefit - since it's so much time and effort for very little again. Truthfully... I enjoy the challenge! And I'm driven further because I can pass on the benefits to others. I do a lot of playing around with mathematics, and when it comes to number crunching, especially for things that can take weeks to complete (e.g. Lucas-Lehmer Primality Testing), even a small saving can multiply into an entire day of saved time. I grew up with Turbo Pascal and then Delphi 2.0 as a pre-teen, and being more of an algorithmic programmer nowadays, I want to be able to say about FreePascal: "This is a good language for time-critical functions". Just a little ambition! Gareth aka. Kit On Mon 25/02/19 18:41 , "Sven Barth" pascaldra...@googlemail.com sent: J. Gareth Moreton schrieb am Mo., 25. Feb. 2019, 19:14: The compiler isn't a valid case because the input source is different (because of the very changes made to said compiler). It needs to be a project that doesn't share anything with the compiler (except the run-time libraries), so the source code is exactly the same so that when it is built, it runs the same no matter which version of the compiler it was built with. I'm viewing it as a bit of a scientific experiment, where only a single variable is changed, namely the compiler used. The compiled program should produce exactly the same output and otherwise behave the same way, so that any time metrics reflect only how long it takes to complete and hence is reflective only of the quality of the machine code, not what the program is doing... if that makes any sense. You could always build an unmodified compiler with your modified one ;) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implicit cast from Char/String to array of Char
Am 25.02.2019 um 08:09 schrieb Ondrej Pokorny:
Hello!
Implicit cast from Char/String to array of Char: is this a wanted
behavior or is it a compiler bug?
(Btw. MODE DELPHI behaves the same).
program Project1;
{$mode objfpc}{$H+}
procedure A(AC: array of Char);
var
C: Char;
begin
for C in AC do
WriteLn(C);
end;
procedure B(AC: array of Integer);
var
C: Integer;
begin
for C in AC do
WriteLn(C);
end;
begin
A('a'); // no error in FPC (error in Delphi)
A('ab'); // no error in FPC (error in Delphi)
B(1); // error in FPC & Delphi
end.
Please note that the error for "B(1)" in FPC is misleading. If you use
"B(Integer(1))" it will work.
The reason is that both FPC and Delphi allow the passing of singular
elements to open array parameters however Delphi does not allow constant
values while FPC does.
Thus it's also clear why "A('a')" is working.
It's unclear however whether "A('ab')" is supposed to be working. I know
that the compiler has some code to convert a string constant to char
arrays, but I don't know if this is intended to be used here as well.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
On Mon, 25 Feb 2019, Bart wrote: Hi, I'm currently involved in some TRegistry bugs and regressions. Personally I don't use TRegistry in any of my programs. Also I mostly use Lazarus, so most most of the issues don't affect me. However I would like to share som observations and thoughts. TRegistry on Windows now (3.2+) uses Unicode API. String input parameters in the various methods get "promoted" to Unicode and then the API is called. Returned string values however are mostly encode in UTF8, by explicitely calling Utf8Encode(SomeUnicodeString). Is that (enforce UTF8 encoding) by design? (The Ansi to Unicode was done via UTF8Decode which is definitively wrong and is fixed by now.) On Lazarus, this no problem, since by default all strings are UTF8 encoded, so all conversions are lossless. I think Lazarus users are the main TRegistry users, so I would keep current behaviour for the public API. Where possible add overloads that use a unicodestring, and let the UTF8 one call the unicode one. Under the hood, you can then completely switch to UnicodeString if that makes it easier. The XML registry also works with Unicode string, since DOM uses unicodestring. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Good timing metric test program?
J. Gareth Moreton schrieb am Mo., 25. Feb. 2019, 19:14: > The compiler isn't a valid case because the input source is different > (because of the very changes made to said compiler). It needs to be a > project that doesn't share anything with the compiler (except the run-time > libraries), so the source code is exactly the same so that when it is > built, it runs the same no matter which version of the compiler it was > built with. > > I'm viewing it as a bit of a scientific experiment, where only a single > variable is changed, namely the compiler used. The compiled program should > produce exactly the same output and otherwise behave the same way, so that > any time metrics reflect only how long it takes to complete and hence is > reflective only of the quality of the machine code, not what the program is > doing... if that makes any sense. > You could always build an unmodified compiler with your modified one ;) Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Good timing metric test program?
On 25.02.2019 19:16, Ondrej Pokorny wrote: On 25.02.2019 18:12, J. Gareth Moreton wrote: The compiler isn't a valid case because the input source is different (because of the very changes made to said compiler). It needs to be a project that doesn't share anything with the compiler (except the run-time libraries), so the source code is exactly the same so that when it is built, it runs the same no matter which version of the compiler it was built with. I'm viewing it as a bit of a scientific experiment, where only a single variable is changed, namely the compiler used. The compiled program should produce exactly the same output and otherwise behave the same way, so that any time metrics reflect only how long it takes to complete and hence is reflective only of the quality of the machine code, not what the program is doing... if that makes any sense. Gareth aka. Kit Build Lazarus? What I meant: build compiler with and without your changes and then compare build times for Lazarus. (So actually you compare the compiler, just like Marco suggested.) Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Good timing metric test program?
On 25.02.2019 18:12, J. Gareth Moreton wrote: The compiler isn't a valid case because the input source is different (because of the very changes made to said compiler). It needs to be a project that doesn't share anything with the compiler (except the run-time libraries), so the source code is exactly the same so that when it is built, it runs the same no matter which version of the compiler it was built with. I'm viewing it as a bit of a scientific experiment, where only a single variable is changed, namely the compiler used. The compiled program should produce exactly the same output and otherwise behave the same way, so that any time metrics reflect only how long it takes to complete and hence is reflective only of the quality of the machine code, not what the program is doing... if that makes any sense. Gareth aka. Kit Build Lazarus? Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Good timing metric test program?
The compiler isn't a valid case because the input source is different (because of the very changes made to said compiler). It needs to be a project that doesn't share anything with the compiler (except the run-time libraries), so the source code is exactly the same so that when it is built, it runs the same no matter which version of the compiler it was built with. I'm viewing it as a bit of a scientific experiment, where only a single variable is changed, namely the compiler used. The compiled program should produce exactly the same output and otherwise behave the same way, so that any time metrics reflect only how long it takes to complete and hence is reflective only of the quality of the machine code, not what the program is doing... if that makes any sense. Gareth aka. Kit On Mon 25/02/19 18:08 , Marco van de Voort f...@pascalprogramming.org sent: Op 2019-02-25 om 14:52 schreef J. Gareth Moreton: > > Given my recent work with the peephole optimizer, one thing that > sprung to mind is that I don't have a project that tests for > performance gains in a 'real world' program, where little > optimisations add up over time. Given that my x86-64 optimizer > overhaul is rather substantial and makes a lot of improvements when it > comes to conditional jumps and code efficiency, is there a benchmark > that could be used to show the performance improvement compared to the > trunk? There are small ones that test individual components, but > nothing substantially large that I'm aware of. > Build the compiler? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org [1] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel [2]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel Links: -- [1] mailto:fpc-devel@lists.freepascal.org [2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Good timing metric test program?
Op 2019-02-25 om 14:52 schreef J. Gareth Moreton: Given my recent work with the peephole optimizer, one thing that sprung to mind is that I don't have a project that tests for performance gains in a 'real world' program, where little optimisations add up over time. Given that my x86-64 optimizer overhaul is rather substantial and makes a lot of improvements when it comes to conditional jumps and code efficiency, is there a benchmark that could be used to show the performance improvement compared to the trunk? There are small ones that test individual components, but nothing substantially large that I'm aware of. Build the compiler? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] TRegistry and Unicode
Hi, I'm currently involved in some TRegistry bugs and regressions. Personally I don't use TRegistry in any of my programs. Also I mostly use Lazarus, so most most of the issues don't affect me. However I would like to share som observations and thoughts. TRegistry on Windows now (3.2+) uses Unicode API. String input parameters in the various methods get "promoted" to Unicode and then the API is called. Returned string values however are mostly encode in UTF8, by explicitely calling Utf8Encode(SomeUnicodeString). Is that (enforce UTF8 encoding) by design? (The Ansi to Unicode was done via UTF8Decode which is definitively wrong and is fixed by now.) On Lazarus, this no problem, since by default all strings are UTF8 encoded, so all conversions are lossless. In a plain fpc program though on Windows, default encoding is the current codepage (cp1252 in my case) and information will get lost when you process the result further. On non-Windows platforms all data in the registry is (supposed to be) UTF8-encoded in a XML file. Since the registry interfaces with a Unicode API (Windows) or UTF8 API (all other platforms), would it maybe make sense to use UnicodeString parameters throughout TRegistry? (UnicodeString because this is primarily used on Windows, otherwise I'ld suggest UTF8String.) Now all conversions from and to UnicodeString are hidden from the programmer, so he/she cannot know that dataloss due to conversion may occur. Using UnicodeString parameters will make the caller aware (if he/she uses AnsiStrings as parameters) that conversion will happen. Pro's - simpler and more consistent code in the Windows implementation of TRegistry - awareness of conversion for the programmer Con's - people will complain about the warnings - XMLReg implentation needs Utf8Encode/Utf8Decode (currently there is no conversion there: even if system codepage is not UTF8, the XML file claims it is, so this might be wrong as is) - UnicodeStrings are slower (my guess is that acessing the API itself is slower than the Pascal code in the registry methods) - We do not have a Unicode TStringList (for ReadStringList/WriteStringList methods) Whilst I know that hardly any fpc devel uses TRegistry, without getting your thoughts and opinions on this matter it makes no sense to suggest patches implementing such a big change. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Good timing metric test program?
Hi everyone, Given my recent work with the peephole optimizer, one thing that sprung to mind is that I don't have a project that tests for performance gains in a 'real world' program, where little optimisations add up over time. Given that my x86-64 optimizer overhaul is rather substantial and makes a lot of improvements when it comes to conditional jumps and code efficiency, is there a benchmark that could be used to show the performance improvement compared to the trunk? There are small ones that test individual components, but nothing substantially large that I'm aware of. Gareth aka. Kit ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
