Recent

Author Topic: Alternative set of string-to-int conversion routines  (Read 26690 times)

avk

  • Hero Member
  • *****
  • Posts: 752
Re: Alternative set of string-to-int conversion routines
« Reply #15 on: January 21, 2022, 06:44:01 am »
I'm glad I was able to help you.

Thaddy

  • Hero Member
  • *****
  • Posts: 14359
  • Sensorship about opinions does not belong here.
Re: Alternative set of string-to-int conversion routines
« Reply #16 on: January 21, 2022, 08:53:02 am »
In principle, using generics (as I suggested too) should not have a speed penalty at all.

In principle. In practice I find that debug sessions on my code regularly take me through the generics unit, which suggests that it /does/ interpose code in various places even when not used explicitly.

MarkMLl
I believe this is only true if you use one of the generic libraries, NOT for completely self defined generic code as one can see from the generated assembler.
E.g. this code, that only uses the system unit:
Code: Pascal  [Select][+][-]
  1. {$mode delphi}
  2. type
  3.   TIntArray = TArray<integer>;
  4.   TStringArray = TArray<string>;
  5.   procedure swap<T>(var left,right:T);inline;
  6.   var
  7.     temp:T;
  8.   begin
  9.     temp:=left;
  10.     left:=right;
  11.     right:=temp;
  12.   end;
  13.  
  14.   procedure Reverse<T>(var Value:TArray<T>);inline;
  15.   var
  16.     i: Integer = 0;
  17.   begin
  18.     if Length(Value) > 0 then
  19.       for i := Low(Value) to High(Value) div 2 do
  20.         Swap<T>(Value[i],Value[High(Value) - i]);
  21.   end;
  22.  
  23. var
  24.   i:integer;
  25.   s:string;
  26.   si:TintArray = [1,2,3,4,5,6,7,8,9,10];
  27.   ss:TStringArray = ['there', 'are', 'more', 'things', 'in', 'heaven', 'and', 'earth',', ', 'Horatio'];
  28. begin
  29.   reverse<integer>(si);
  30.   for i in si do write(i:2);
  31.   writeln;
  32.   reverse<string>(ss);
  33.   for s in ss do write(s:length(s)+1);
  34. end.
The assembler shows that the "templates" are filled in *before* any assembler code is generated.
There is simply no reference to anything "generics" in the generated code apart from possibly internal namings.
There is simply no codepath related to generics at all.
I compiled this with -al -CX -XXs -O4
I also tested a non-generic version if Int reverse: Hey, near identical code!
« Last Edit: January 21, 2022, 09:39:24 am by Thaddy »
Object Pascal programmers should get rid of their "component fetish" especially with the non-visuals.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6682
Re: Alternative set of string-to-int conversion routines
« Reply #17 on: January 21, 2022, 09:31:58 am »
I believe this is only true if you use one of the generic libraries, NOT for completely self defined generic code as one can see from the generated assembler.

I can only assume that it's somewhere in the standard FPC or LCL libraries. It's definitely not anything that I've done explicitly.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Thaddy

  • Hero Member
  • *****
  • Posts: 14359
  • Sensorship about opinions does not belong here.
Re: Alternative set of string-to-int conversion routines
« Reply #18 on: January 21, 2022, 09:41:37 am »
I can only assume that it's somewhere in the standard FPC or LCL libraries. It's definitely not anything that I've done explicitly.

MarkMLl
That seems strange to me. My example only uses system and no libraries at all.
In fact, it shows using generics for those string to int conversions is a viable option without loss of speed.
The generated code is even inlined.

If you can disproof this, pls show me what happens at your side.
« Last Edit: January 21, 2022, 09:57:16 am by Thaddy »
Object Pascal programmers should get rid of their "component fetish" especially with the non-visuals.

zamtmn

  • Hero Member
  • *****
  • Posts: 594
Re: Alternative set of string-to-int conversion routines
« Reply #19 on: January 21, 2022, 10:02:32 am »
Geneticists are still making debugging very difficult, and may even affect the build due to compiler bugs. But they make readable code and errors will be fixed (but not as fast as I would like)

Thaddy

  • Hero Member
  • *****
  • Posts: 14359
  • Sensorship about opinions does not belong here.
Re: Alternative set of string-to-int conversion routines
« Reply #20 on: January 21, 2022, 10:09:06 am »
So what is difficult? As long as you specialize at type level the debugger has no issues, at least I did not encounter them. I am aware that if you specialize at var level the debugger does not always play nice. That is an important distinction.
Code: Pascal  [Select][+][-]
  1. type
  2.   TIntArray = TArray<integer>;
  3.   TStringArray = TArray<string>;
Note I use fp + GDB.
« Last Edit: January 21, 2022, 10:14:52 am by Thaddy »
Object Pascal programmers should get rid of their "component fetish" especially with the non-visuals.

zamtmn

  • Hero Member
  • *****
  • Posts: 594
Re: Alternative set of string-to-int conversion routines
« Reply #21 on: January 21, 2022, 10:14:27 am »
I have often encountered an incorrect display of the current executed line, it is shifted 1-2 up or down

Thaddy

  • Hero Member
  • *****
  • Posts: 14359
  • Sensorship about opinions does not belong here.
Re: Alternative set of string-to-int conversion routines
« Reply #22 on: January 21, 2022, 10:15:49 am »
I have often encountered an incorrect display of the current executed line, it is shifted 1-2 up or down
How did you specialize? type level or var level? Can you give us a small example to reproduce?

GDB is GNU gdb unicode (GDB) 9.2
« Last Edit: January 21, 2022, 10:22:53 am by Thaddy »
Object Pascal programmers should get rid of their "component fetish" especially with the non-visuals.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6682
Re: Alternative set of string-to-int conversion routines
« Reply #23 on: January 21, 2022, 10:22:27 am »
I can only assume that it's somewhere in the standard FPC or LCL libraries. It's definitely not anything that I've done explicitly.

MarkMLl
That seems strange to me. My example only uses system and no libraries at all.
In fact, it shows using generics for those string to int conversions is a viable option without loss of speed.
The generated code is even inlined.

If you can disproof this, pls show me what happens at your side.

I'll report back if I can spot what's going on.

Please note that I'm not commenting on an observed performance issue, merely that the generics library is insinuating itself /somewhere/ so there's the /potential/ for a performance issue if a shim is being traversed e.g. inside a tight loop.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

zamtmn

  • Hero Member
  • *****
  • Posts: 594
Re: Alternative set of string-to-int conversion routines
« Reply #24 on: January 21, 2022, 10:23:59 am »
I specialize in different ways, but I try to do in types, I'm talking about debugging inside generics classes

Thaddy

  • Hero Member
  • *****
  • Posts: 14359
  • Sensorship about opinions does not belong here.
Re: Alternative set of string-to-int conversion routines
« Reply #25 on: January 21, 2022, 10:25:38 am »
Please note that I'm not commenting on an observed performance issue, merely that the generics library is insinuating itself /somewhere/ so there's the /potential/ for a performance issue if a shim is being traversed e.g. inside a tight loop.

MarkMLl
I think the latter is wrong. But I am open to further testing.
Object Pascal programmers should get rid of their "component fetish" especially with the non-visuals.

Thaddy

  • Hero Member
  • *****
  • Posts: 14359
  • Sensorship about opinions does not belong here.
Re: Alternative set of string-to-int conversion routines
« Reply #26 on: January 21, 2022, 10:27:29 am »
I specialize in different ways, but I try to do in types, I'm talking about debugging inside generics classes
That is no issue if you specialize at type level and debug the specialization, not the template - which is not there for the debugger to see.
Object Pascal programmers should get rid of their "component fetish" especially with the non-visuals.

zamtmn

  • Hero Member
  • *****
  • Posts: 594
Re: Alternative set of string-to-int conversion routines
« Reply #27 on: January 21, 2022, 10:32:26 am »
That is no issue if you specialize at type level and debug the specialization, not the template - which is not there for the debugger to see.
I know your point of view - it's not a compiler problem, it's a bad programmer's problem)) But no. Debugging the code is also necessary inside the genetic classes and it is very difficult

Thaddy

  • Hero Member
  • *****
  • Posts: 14359
  • Sensorship about opinions does not belong here.
Re: Alternative set of string-to-int conversion routines
« Reply #28 on: January 21, 2022, 10:38:18 am »
I know your point of view - it's not a compiler problem, it's a bad programmer's problem)) But no. Debugging the code is also necessary inside the genetic classes and it is very difficult
Well, no, that is not what I wrote. Both ways to specialize are fully legal.
Specialized at type level it isn't even possible - by sheer logic - to debug the template code, afaik there is none.
Maybe @PascalDragon can help us here.... Sarah? Or @FPK himself?

Note that this may seem to some a side discussion but it isn't: once we fully understand what is going on, we can help and improve on the original subject's code. At least that is how I think: we have to establish the facts.
« Last Edit: January 21, 2022, 10:47:42 am by Thaddy »
Object Pascal programmers should get rid of their "component fetish" especially with the non-visuals.

zamtmn

  • Hero Member
  • *****
  • Posts: 594
Re: Alternative set of string-to-int conversion routines
« Reply #29 on: January 21, 2022, 12:03:08 pm »
Maybe this is Lazarus' problem, I can't reproduce this in a minimal example. I think that with some changes in the generic source code, EXE or PPU remain old, and this causes incorrect display of the executed lines. It's related https://gitlab.com/freepascal.org/fpc/source/-/issues/39387

 

TinyPortal © 2005-2018