Re: [fpc-pascal] Generics vs templates
Am 10.01.2018 05:10 schrieb "Ryan Joseph" : > On Jan 10, 2018, at 6:37 AM, Graeme Geldenhuys < mailingli...@geldenhuys.co.uk> wrote: > > When using the Generics.Collections unit of Delphi I can define a list class that can hold Integer data types, by doing the following: > > var >IntList: TList; > begin >IntList := TList.Create; >IntList.Add(12345); I presume then TList<> and TList class are not implemented the same then because I still don’t know how the generic itself affects runtime performance. Btw this looks like C# code because C# explicitly does not specialize at compile time but rather runtime so every instance will be using TList. Does Delphi do this also? I think FPC requires you MUST specialize at compile time so simply using TList won’t compile. That are two orthogonal points. FPC and Delphi both allow inline specializations which is what you see above (in the non-Delphi modes of course with the "specialize" keyword). That doesn't change that such specializations are done at compile time. For the compiler it is as if the type "TList" exists as a full type wherever it is used. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generics vs templates
Am 10.01.2018 07:39 schrieb "Marco van de Voort" : In our previous episode, Sven Barth via fpc-pascal said: > Precisely these virtual methods are one point. They might not add much by > themselves, but if they're called for each Add or Remove operation they can > add quite a bit. > Why do you think that the TFP(Object)List classes don't have notification > support unlike T(Object)List? Even if it only checks whether a notification > handler is assigned it's enough for a noticeable difference in performance. But Graeme compared Delphi TList to Delphi TList<> so both have notifiers? That was more about what a difference the existence of notifiers can have to highlight what performance difference generic capable code can have compared to non-generic code. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generics vs templates
In our previous episode, Sven Barth via fpc-pascal said: > Precisely these virtual methods are one point. They might not add much by > themselves, but if they're called for each Add or Remove operation they can > add quite a bit. > Why do you think that the TFP(Object)List classes don't have notification > support unlike T(Object)List? Even if it only checks whether a notification > handler is assigned it's enough for a noticeable difference in performance. But Graeme compared Delphi TList to Delphi TList<> so both have notifiers? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generics vs templates
> On Jan 10, 2018, at 6:37 AM, Graeme Geldenhuys > wrote: > > When using the Generics.Collections unit of Delphi I can define a list class > that can hold Integer data types, by doing the following: > > var >IntList: TList; > begin >IntList := TList.Create; >IntList.Add(12345); I presume then TList<> and TList class are not implemented the same then because I still don’t know how the generic itself affects runtime performance. Btw this looks like C# code because C# explicitly does not specialize at compile time but rather runtime so every instance will be using TList. Does Delphi do this also? I think FPC requires you MUST specialize at compile time so simply using TList won’t compile. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Problems with writing to console
I suspect the output when writing to StdOut is moving the cursor to a location that is not known or kept track of by regular writeln in the CRT unit. If this is what's causing seemingly random positioning, You could possibly keep track of where the cursor is supposed to be yourself with the CRT functions WhereX32 & WhereY32 then move the cursor to a fixed position with the CRT function GotoXY32 , perform the Writeln to StdOut, then move the cursor back to the position saved by WhereX32/WhereY32 with another GotoXY32. You mentioned you have several applications that work together, so maybe you can somehow use these functions to keep things straight in the console window, by possibly parking the cursor in a known position and relaying the position to the other program. One problem with using WhereX32, WhereY32, and GotoXY32 with windows consoles, is that the console window is not a predetermined shape, it depends on how the user has the system configured. You can get around this two ways: 1. by detecting the existing shape of the console window with GetConsoleScreenBufferInfo() Now you will know the shape of the console window and stay within it. 2. force the windows console window to be particular shape with SetConsoleWindowInfo(); and you can also force a particular console screen buffer with SetConsoleScreenBufferSize(); I believe there is also a way to force the font, and font size for windows consoles as well. I've attached a CRT Demo program that uses the above functions as an example. It's not clear If you are using StdOut for redirection purposes, however if the output is redirected, none of this will work, because as Michael mentioned, CRT with redirection is not supported.. if you try it, StdOut is all that is redirected and Output is just lost. so then you don't have anything on the screen and none of the positioning will mean anything. I did notice you can also write stuff to StdErr and it will redirect separately from output with 2> but if you use 2>&1 then you get no screen output. So if you did want some stuff on the screen and to redirect other stuff, then the stuff you want redirected could be done with stderr and you could also still use positioning functions for normal output. I attached another sample program that demonstrates this, try to run it with various redirects and it will be clear what is redirected and what isn't It also shows writing things to stderr then using gotoxy32 to write over it so it won't even show up on the screen. If the program is run without redirection. (set wait4key to false to see this) James -Original Message- From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of Michael Van Canneyt Sent: Tuesday, January 09, 2018 7:16 PM To: FPC-Pascal users discussions Subject: Re: [fpc-pascal] Problems with writing to console On Tue, 9 Jan 2018, Darius Blaszyk wrote: > Hi, > > I have been mixing "writeln(StdOut" and regular writeln in my > application (actually a couple of applications working together) and > found that the output on the console is mangled when I do that. Output > is being overwritten and placed semi randomly on the console. What is > the standard output for writeln? I thought it would be StdOut as the > name suggests. Using StdOut at the same time will not allow colors > (TextColor) from the crt unit to be shown on the console. On the other > hand reading output from the console does require writing to StdOut. Take care, stdout and output are not the same text file. if no file is specified, then output is assumed. The crt unit only redirects output. not stdout. (See around line 438 of crt.inc) using crt and output redirection together is not supported. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal Console_Size_Detect_Demo.pas Description: Binary data test.pas Description: Binary data ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Problems with writing to console
On Tue, 9 Jan 2018, Darius Blaszyk wrote: Hi, I have been mixing "writeln(StdOut" and regular writeln in my application (actually a couple of applications working together) and found that the output on the console is mangled when I do that. Output is being overwritten and placed semi randomly on the console. What is the standard output for writeln? I thought it would be StdOut as the name suggests. Using StdOut at the same time will not allow colors (TextColor) from the crt unit to be shown on the console. On the other hand reading output from the console does require writing to StdOut. Take care, stdout and output are not the same text file. if no file is specified, then output is assumed. The crt unit only redirects output. not stdout. (See around line 438 of crt.inc) using crt and output redirection together is not supported. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generics vs templates
On 2018-01-09 01:29, Ryan Joseph wrote: What does this have to do with generics exactly? Everything I guess. ;-) That was the point of my reply. When using the Generics.Collections unit of Delphi I can define a list class that can hold Integer data types, by doing the following: var IntList: TList; begin IntList := TList.Create; IntList.Add(12345); How Generics does that (how it is implemented underneath), I don't know - I never bothered to look. All I'm saying is that in our company the developers love Generics, but then can't understand why performance degrades is some areas of our project. Further testing revealed that the usage of Generics was partly to blame. I then investigated this, and compared some of those lists, and implementing the equivalent manually (using TList, TObjectList and such). For example, the above code example can be accomplish with a TList only. var IntList: TList; begin IntList := TList.Create; IntList.Add(Pointer(12345)); Yes, the second code sample might not look so nice (the casting), but it was just the simplest and quickest example I could knock up to store integers in a list. Either way, the non-Generics code example was considerably faster in adding and freeing itself. This was just one example. TObjectList (or a customised descendant... eg: TAddressList) was another case where it was way faster than Generics.Collections.pas unit provided. Like I said, this was all tested under Delphi XE3. I didn't have time today to test under FPC, but will try and do so tomorrow. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Comp type
Comp is Int64 div 1. Thanks for the explanation Mathias! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Comp type
On Tue, 09 Jan 2018 22:58:01 +0100 Darius Blaszyk wrote: > By accident I noticed the comp type for the first time. It's an Int64 > but is considered to be a real type. Just out of curiosity, what is the > use case of such a type, or is this just implemented for compatibility > reasons? Comp is Int64 div 1. So it is a real, but not a float. This has some advantages computing things like money. For example it can represent numbers like 0.3 exactly, which is not possible with double. Also computing integers is often faster than doubles. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Problems with writing to console
Hi, I have been mixing "writeln(StdOut" and regular writeln in my application (actually a couple of applications working together) and found that the output on the console is mangled when I do that. Output is being overwritten and placed semi randomly on the console. What is the standard output for writeln? I thought it would be StdOut as the name suggests. Using StdOut at the same time will not allow colors (TextColor) from the crt unit to be shown on the console. On the other hand reading output from the console does require writing to StdOut. So I guess my question is, How can I use color, and read the output with a TProcess from the console? If I get a solution for that I will not need to mix different output text files. I'm using Windows and FPC 3.0.4 btw. I have not yet tested Linux nor macOS. Appreciate any help. TIA! Rgds, Darius___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Comp type
By accident I noticed the comp type for the first time. It's an Int64 but is considered to be a real type. Just out of curiosity, what is the use case of such a type, or is this just implemented for compatibility reasons? Rgds, Darius___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generics vs templates
2018-01-08 21:30 GMT+01:00 Graeme Geldenhuys : > Speaking of Generics and Benchmarks. Has anybody done some benchmarks on > FPC's Generics vs "old-school" TList and TObjectList. Recently I did a very > simple test with Delphi XE3 using TList and a stock TList. Adding > 50,000 and 200,000 integer values to each list, and timing the creation of > the list and population of the list. Then I also timed the destruction of > the list. I was horified to find out how much slower Delphi's Generics were > compared to TList and TObjectList. Destruction was 250x slower in many > cases. Creation and population of the list was 5x-10x slower. > > Lets hope FPC fares better. If nobody has done such tests, I can do it > tomorrow at work with the same Delphi test code I created. > It depends on use case and on library design. For example in the FPC case, generic TList has better performance for larger lists (the capacity uses golden ratio) than regular TList (for Integers). The performance difference in daily usage is rather minor (if any). We have available detailed tests for generic and non generics hash maps thanks to Benito van der Zander (FPC has so many different maps! :) ): http://www.benibela.de/fpc-map-benchmark_en.html The results for rtl-generics should be better soon. I am working on new version of rtl-generics library, so all should works faster (better hashing function + optimizations for managed types - especially improved for incoming smart pointers/objects). -- Best regards, Maciej Izak ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generics vs templates
Am 09.01.2018 08:13 schrieb "Ryan Joseph" : > On Jan 9, 2018, at 2:04 PM, Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > > But you need to program in a way that allows the usage of multiple, different types. That can more often than not lead to worse performance. > Examples? I had to add some if statements in a couple areas I didn’t want to and a virtual method but beyond that I don’t see what would affect performance. Precisely these virtual methods are one point. They might not add much by themselves, but if they're called for each Add or Remove operation they can add quite a bit. Why do you think that the TFP(Object)List classes don't have notification support unlike T(Object)List? Even if it only checks whether a notification handler is assigned it's enough for a noticeable difference in performance. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] re-engineering tool
On Mon, 2018-01-08 at 15:21 +0200, Juha Manninen wrote: > On Sat, Jan 6, 2018 at 11:46 AM, Marc Santhoff > wrote: > > Since I'm confronted with the task of analyzing a pile of object > > pascal > > sources I'd like to know: > > > > Is there any tool that can help me? > > > > Automatically generating a visual class diagram having uses and > > aggregation of other classes would be very helpful. > > There is also a Lazarus port of Ess-Model called Laz-Model. > See: > https://github.com/dicepd/Laz-Model > It is indeed a reverse-engineering class diagram tool. Beautiful, open source and fpc code aware. I think I'll try that one first. :) Many thanks, Marc -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
