Re: [fpc-devel] Performance of string handling in trunk
On 06/20/2013 05:31 PM, luiz americo pereira camara wrote: The point is that i would expect a smaller performance hit when there's no conversion going on. Something between 10% slower. In the cited case is more than 50% slow. As the dynamic types of (most) String Variables are already defined and known at compile time, and thus (usually) the library does not need to detect the encoding in realtime, the performance hit should be close to zero, as long as the same String encoding is used as with the non-(DXE-compatible)-Unicode project with the same source code. OTOH, if the former version used 1-Byte-Strings (ANSI or UTF-8) and the new version used 16 or 32 bit Strings (UTF-16 or UTF32) I would expect a severe performance hit as well because more bytes need to be moved and because the cache gets a lot more tight because of the double memory usage. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Performance of string handling in trunk
On 06/20/2013 05:31 PM, luiz americo pereira camara wrote: Maybe in that example there's going an (unneeded) conversion? If you use the same string type all over the place it would be a severe bug if _any_ conversion is done. Please check. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] where do download BinUtils for ARM - Raspberry Pi?
On 06/19/2013 06:10 PM, Dennis Poon wrote: I have mostly given up on creating the cross compiler for MIPSEB-OpenWrt (or DD-WRT) platform. That is a shame ! (When the time comes,) I would be very interested in a decently supported MIPS compiler and IDE-support, as the PIC32 series, that is based on a MIPS CPU, offers a lot of really nice and cheap chips and rumors say that there very soon will be even more, providing lots of internal RAM and FLASH. Now, my plan B is to create a cross compiler (from x86 Linux) to ARM-Raspberry Pi I don't understand why RPI (still) gets so much interest. A friend of mine just bought two BeagleBone Black boards for EUR 38.- (+VAT) each. With the extremely versatile and well supported TI 1 GHz chip (that is taken from TI's AM... series of devices for embedded use instead of for cellphone use), with 512 MB RAM and additional internal SD-Card, and with a HDMI socket. He is up to try to install and develop with FPC/Lazarus ASAP. (Please com back with any question on that behalf, I'm going to forward them.) I definitively would use this board for my future embedded projects. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] where do download BinUtils for ARM - Raspberry Pi?
On 06/19/2013 06:10 PM, Dennis Poon wrote: I will be happy to use one for ARM debian. My Pal did some initial tests with the BeagleBone Black. Same comes with a Aengstrom Linux pre-installed in it's internal Flash-Card. As he already has some experience with (PC-) Debian, he is going to move his BBB's to same. Additionally, I learned that, for embedded use, the DaVinci distribution also often is recommended. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Performance of string handling in trunk
Michael Schnell schrieb: On 06/20/2013 05:31 PM, luiz americo pereira camara wrote: The point is that i would expect a smaller performance hit when there's no conversion going on. Something between 10% slower. In the cited case is more than 50% slow. As the dynamic types of (most) String Variables are already defined and known at compile time, and thus (usually) the library does not need to detect the encoding in realtime, the performance hit should be close to zero, as long as the same String encoding is used as with the non-(DXE-compatible)-Unicode project with the same source code. Right. Even with RawByteString the test for same encoding should not take considerable time (compared with memory allocation...). Different encodings require to convert both arguments into Unicode, and the result back into the target encoding. OTOH, if the former version used 1-Byte-Strings (ANSI or UTF-8) and the new version used 16 or 32 bit Strings (UTF-16 or UTF32) I would expect a severe performance hit as well because more bytes need to be moved and because the cache gets a lot more tight because of the double memory usage. Again I'd assume that the memory allocation for the result is the most expensive operation with UnicodeString operands, independent from string lengths. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Performance of string handling in trunk
On 06/21/2013 09:54 AM, Hans-Peter Diettrich wrote: Again I'd assume that the memory allocation for the result is the most expensive operation with UnicodeString operands, independent from string lengths. Do you suggest that with UnicodeString - even when using 1 Byte encoding types such as ANSIxxx or UTF-8 -, the memory allocation is more expensive than with the older String handling implementation ? Why ? In fact, the additional some 8 bytes for the Code-Element-Length and Code-Type definition (additional to the already existing String-Length, Content-Address and Ref-Count DWords) should not matter at all. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Performance of string handling in trunk
Michael Schnell schrieb: On 06/21/2013 09:54 AM, Hans-Peter Diettrich wrote: Again I'd assume that the memory allocation for the result is the most expensive operation with UnicodeString operands, independent from string lengths. Do you suggest that with UnicodeString - even when using 1 Byte encoding types such as ANSIxxx or UTF-8 -, the memory allocation is more expensive than with the older String handling implementation ? Please note that I was *not* talking about AnsiStrings. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Performance of string handling in trunk
2013/6/21 Michael Schnell mschn...@lumino.de: On 06/20/2013 05:31 PM, luiz americo pereira camara wrote: Maybe in that example there's going an (unneeded) conversion? If you use the same string type all over the place it would be a severe bug if _any_ conversion is done. Please check. The affected code can be seen here http://forum.lazarus.freepascal.org/index.php/topic,21223.0.html . I don't have a 2.7.1 setup so i cant debug myself. I'm just reporting what the user found Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Performance of string handling in trunk
On 06/21/2013 02:20 PM, Hans-Peter Diettrich wrote: Please note that I was *not* talking about AnsiStrings. Sorry I don't understand. I recon the OP asking about a performance hit, meant a degradation regarding the new (Delphi XE compatible) vs the old (Delphi 7 compatible) String library. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Performance of string handling in trunk
On 21.06.2013 17:11, luiz americo pereira camara wrote: 2013/6/21 Michael Schnell mschn...@lumino.de: On 06/20/2013 05:31 PM, luiz americo pereira camara wrote: Maybe in that example there's going an (unneeded) conversion? If you use the same string type all over the place it would be a severe bug if _any_ conversion is done. Please check. The affected code can be seen here http://forum.lazarus.freepascal.org/index.php/topic,21223.0.html . I don't have a 2.7.1 setup so i cant debug myself. I'm just reporting what the user found I've profiled the code and found no conversions taking place. All the slowdown appears to be caused by other reasons, hard to tell the topmost contributor. What catches the eye is the large amount of calls to UniqueString, and the fact that SetCodePage goes through implicit try..finally block even if it does not need to convert the string. Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Performance of string handling in trunk
On 06/21/2013 04:29 PM, Sergei Gorelkin wrote: What catches the eye is the large amount of calls to UniqueString, It would be interesting to see whether the old (not new Unicode library) project does the same amount of UniqueString. I don't see why the new library should do more of these calls or why they should be slower (while using the same encoding.) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] where do download BinUtils for ARM - Raspberry Pi?
I have successfully compiled my lnet+SSL program on Raspberry Pi. Due to its slow CPU, it took a while but everything worked :-) Good to know there are more low-cost easy to use ARM platform in the market. Please do share your experience with BeagleBone especially on how to write OSless FPC applications on it. That should tremendously reduce the boot time. Currently Pi took 20 seconds to boot to text shell of the default OS Raspbian. Hear for ArchLinux, it takes 10. How long does BeagleBone take to boot to shell? I suppose an embedded (OS-less) app shall boot very quickly. Dennis Michael Schnell wrote: On 06/19/2013 06:10 PM, Dennis Poon wrote: I have mostly given up on creating the cross compiler for MIPSEB-OpenWrt (or DD-WRT) platform. That is a shame ! (When the time comes,) I would be very interested in a decently supported MIPS compiler and IDE-support, as the PIC32 series, that is based on a MIPS CPU, offers a lot of really nice and cheap chips and rumors say that there very soon will be even more, providing lots of internal RAM and FLASH. Now, my plan B is to create a cross compiler (from x86 Linux) to ARM-Raspberry Pi I don't understand why RPI (still) gets so much interest. A friend of mine just bought two BeagleBone Black boards for EUR 38.- (+VAT) each. With the extremely versatile and well supported TI 1 GHz chip (that is taken from TI's AM... series of devices for embedded use instead of for cellphone use), with 512 MB RAM and additional internal SD-Card, and with a HDMI socket. He is up to try to install and develop with FPC/Lazarus ASAP. (Please com back with any question on that behalf, I'm going to forward them.) I definitively would use this board for my future embedded projects. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel No virus found in this message. Checked by AVG - www.avg.com http://www.avg.com Version: 2013.0.3345 / Virus Database: 3199/6428 - Release Date: 06/20/13 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Performance of string handling in trunk
Michael Schnell schrieb: On 06/21/2013 02:20 PM, Hans-Peter Diettrich wrote: Please note that I was *not* talking about AnsiStrings. Sorry I don't understand. You snipped the context, which was UnicodeString (second case). The AnsiString case was covered before. I recon the OP asking about a performance hit, meant a degradation regarding the new (Delphi XE compatible) vs the old (Delphi 7 compatible) String library. Right, and there seem to be more issues with the current implementation. E.g. I don't understand the many tests in the RawByteString concatenation, and others found excess try-finally blocks and UniqueString calls. Another reason may be the (old?) TStringList in the test program, possibly using AnsiStrings, which will cause overhead when used with UnicodeStrings. I didn't do own researches yet, my statements are based on general considerations and a perfect implementation. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] where do download BinUtils for ARM - Raspberry Pi?
Am 21.06.2013 09:32, schrieb Michael Schnell: A friend of mine just bought two BeagleBone Black boards for € 38.- (+VAT) each. With the extremely versatile and well supported TI 1 GHz chip (that is taken from TI's AM... series of devices for embedded use instead of for cellphone use), with 512 MB RAM and additional internal SD-Card, and with a HDMI socket. Does it have an fpu which supports exception handling? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Performance of string handling in trunk
Am 21.06.2013 10:36 schrieb Michael Schnell mschn...@lumino.de: On 06/21/2013 09:54 AM, Hans-Peter Diettrich wrote: Again I'd assume that the memory allocation for the result is the most expensive operation with UnicodeString operands, independent from string lengths. Do you suggest that with UnicodeString - even when using 1 Byte encoding types such as ANSIxxx or UTF-8 -, the memory allocation is more expensive than with the older String handling implementation ? Just to clear up the names: UnicodeString is *not* the code page aware string type (although they share the metadata record). It is a dynamic length 2 byte string. The code page aware string type is AnsiString. Regards Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
