Concat strings in parallel

[LemonParty]

Off topic

I noticed you set the debugger for the project to GDB. Is there a reason? Was there a particular issue that FpDebug could not solve for this? (Unless you are running Windows an ARM)

I tried set Debugger Backend to FpDebug and as a result debugging not work.

[Martin_fr]

Also note that strings are inherently not thread safe, so never touch the same string in different threads

Actually, if you have the string in local vars (or threadvar) => so each thread has its own refcount => then afaik they are. It's just getting that initial copy.

Instead split the array up into regions (e.g. index 1..10, 11..20 etc) and have the algorithm work on that in parallel.

And even then...

Maybe, if all data happens to be in the CPU cache. Not sure how likely that is. But, since it wouldn't be in the correct per-core cache, that would likely at best be level 3 cache. No idea if that is sufficient to feed all cores with data, so none ever has to wait.

But, its more likely that you need to fetch the data from the actual RAM. Then your RAM speed is going to be the bottleneck, and threads would just need to wait for that.

That may differ, if you have millions of very small strings. You still hit RAM bottlenecks, but since you have to do a little bit of computing between the "moves" the threads may get some work to do.

[Martin_fr]

Off topic

I noticed you set the debugger for the project to GDB. Is there a reason? Was there a particular issue that FpDebug could not solve for this? (Unless you are running Windows an ARM)

I tried set Debugger Backend to FpDebug and as a result debugging not work.

What error? (Sorry to take this off topic, but trying to understand if/where fpdebug needs fixes)

I started you project in FpDebug. No issues.
Well, it has different display for malformed chars in strings (since your strings don't contain real text).

You are using "type object" => there is a bug in FPC (but that affects gdb and fpdebug). To debug inside TMaster.OnTerminate you must either use Dwarf-2 or fpc 3.3.1.
https://wiki.freepascal.org/DWARF#DWARF_version_comparison


-- EDIT: Lazarus 4.n ?

[Warfley]

But, its more likely that you need to fetch the data from the actual RAM. Then your RAM speed is going to be the bottleneck, and threads would just need to wait for that.

That may differ, if you have millions of very small strings. You still hit RAM bottlenecks, but since you have to do a little bit of computing between the "moves" the threads may get some work to do.

If the string concat is done naively than the main bottle neck is memory allocation anyways. What could be more efficient is the following:
1. iterate through all strings to compute the total length for the allocation
2. spawn threads over a certain number of strings, with a pointer to the result buffer location.
3. each thread only accesses the strings as raw pointers (not triggering refcounting) to copy bytes over
4. when all threads are finished the main thread can use the buffer

If those strings are allocated closely together, or are long enough so they get cached well, it should be able to get some performance benefit

[LemonParty]

Off topic

I noticed you set the debugger for the project to GDB. Is there a reason? Was there a particular issue that FpDebug could not solve for this? (Unless you are running Windows an ARM)

I tried set Debugger Backend to FpDebug and as a result debugging not work.

What error? (Sorry to take this off topic, but trying to understand if/where fpdebug needs fixes)

I started you project in FpDebug. No issues.
Well, it has different display for malformed chars in strings (since your strings don't contain real text).

You are using "type object" => there is a bug in FPC (but that affects gdb and fpdebug). To debug inside TMaster.OnTerminate you must either use Dwarf-2 or fpc 3.3.1.
https://wiki.freepascal.org/DWARF#DWARF_version_comparison


-- EDIT: Lazarus 4.n ?

Lazarus 4.99
How do you set up debugger to use FpDebug?

[Thaddy]

It does by default on supported platforms.

[440bx]

How do you set up debugger to use FpDebug?

using the main menu, goto
 Tools->Options->Debugger->Debugger backend

the very top line is a selection box that allows you to select the backend.

see the attachment.

[Martin_fr]

Lazarus 4.99
How do you set up debugger to use FpDebug?

Just like the image here https://wiki.freepascal.org/Debugger_Setup#Setting_up_the_debugger_backend_for_the_IDE

And in "project options", the debugger is set to "use IDE default debugger".
It can also be set to "Use project debugger", IF there is no project debugger. (Then a red label will state that it uses the IDE debugger).


On the Tools > Options > Debugger > Debugger Backend - page, you don't need to change anything inside the grid. Leave all at defaults.

If you don't have an "FpDebug" entry (raw case, upgrades from custom debug configs of much older IDE versions), then use "Add" to create a new backend.
Don't do "Change type" on an existing backend.
When you do "add", you set the "type" once (to FpDebug").

---
Some of the options in the grid are explained here https://wiki.freepascal.org/LazDebuggerFp

- You need an Intel/AMD CPU
- ARM/AARCH is not supported (for that you need gdb)
- FpDebug can debug 64 and 32 bit. It can also cross debug a 32 bit target in a 64 bit IDE.
- FpDebug can not cross debug a 64bit target in a 32 bit IDE

[LemonParty]

When I press "Add" a "New [GNU debugger (gdb)]" is added. And in this case debugging not work. When I change Debugger type to FpDebugger debugging also not work.

[Martin_fr]

When I press "Add" a "New [GNU debugger (gdb)]" is added. And in this case debugging not work. When I change Debugger type to FpDebugger debugging also not work.

First of all: there are 2 places where you can set a "debugger backend"

1) Global: Menu: Tools > Options => Debugger > Debugger Backend
2) Per Project: Project Options => Project Options > Debugger

Your image shows the 2nd.

Usually, you leave the settings in the "project options" alone. They are meant if you need to change debugger for a single project (e.g. you need a debug server for remote debugging).

But, of course if you want to try it on the current project first, and not change your global settings, then you can use that too.

----

In you image, when you press add, then the new debugger backend has indeed "Gnu Debugger (gdb)" preselected in the drop down.

You can change that in the drop down to "FpDebug internal DWARF debugger".
(If you do, the "path" edit will be immediately disabled).

Once you change it, the drop down takes the new value and immediately becomes disabled => your choice is taken and locked
(but the "Change type" button allows you to edit it again, if you selected the wrong value).

The name you can then change as you want (or leave as it is).

----
In your image it says in red "Using selected IDE debugger settings".

=> that is you are using the "debugger backend" as specified by the drop down on the very top of the page.

The newly added is ignored, until you change the "debugger backend" dropdown (at the very top) to "-- Use project debugger --".



Given that (in the "debugger backend" dropdown) it currently says "FpDebug" => you are using the FPDebug backend from the global "Tools > Options > Debugger Backend".

You can go to Tools > Options to inspect the setup of that backend.

-----

See also https://wiki.freepascal.org/IDE_Window:_Project_Options_-_Debugger_Backend


The question still remains:

And in this case debugging not work.

How exactly does it not work. What happens when you try to debug?

[Martin_fr]

I started a thread on the debugger setup pages https://forum.lazarus.freepascal.org/index.php?topic=72255

Trying to find out were they may mislead and potentially how to improve them.

[LemonParty]

How exactly does it not work. What happens when you try to debug?

Blue bubbles on the left side of editor not appear and breakpoints not work.

I changed settings from Menu: Tools > Options => Debugger > Debugger Backend and again debugging not work with FpDebug.

[Warfley]

Is you procedure inlined?

[LemonParty]

Is you procedure inlined?

No.

[Martin_fr]

Is you procedure inlined?

He had it originally working with GDB, at least that is my understanding. So the compiler settings should be fine. Unless he had chosen "STABS", but then the IDE would force him to change that (the infamous "which dwarf" dialog). So that ain't it either.

How exactly does it not work. What happens when you try to debug?

Blue bubbles on the left side of editor not appear and breakpoints not work.

I changed settings from Menu: Tools > Options => Debugger > Debugger Backend and again debugging not work with FpDebug.

Ok, so a debugger is running => without it the IDE would not show blue dots. And it also means the debug info is fine (i.e. if the debugger is FpDebug, then it is DWARF, or the blue dot info would not have been there).

Off the top of my head, reasons for not stopping at a breakpoint.

None off them seem to apply to the attached test project.

- Breakpoint at a line that does not have a blue dot.
=> gdb will stop at the next line (even if that is 1000 lines down)
=> FpDebug will for up to 3 or 4 lines (but not in older IDE)
  Though the answer was 4.99 => then it should.
  Anyway try it on a line that has a blue dot, in case you had it at a line before.

If you were more than 4 lines (empty/comment lines) above the next blue dot, then that would explain it.

* Which color does the breakpoint have? Red, Orange, Green?
* What symbol is shown on the breakpoint: Question mark, X/Cross, Check/Tick/Ok-Sym, "pause" (2 bars) ?

Dead code
"if false then" or entire procedures that are never called...
may lead to code with blue dots...
Yet, if gdb stopped.... Then that is not it...

inlined
will efficiently not be called. The inlined code is all at the one line that has the call to the procedure
Yet, if gdb stopped.... Then that is not it...

generics
I am not sure, IIRC depends on FPC version => sometimes specialized generics are attributed to the wrong unit, then they wont stop (they can be stepped into, but with side effects.)
Yet, if gdb stopped.... Then that is not it...


Just looked at the project again: External debug info That should work. But it be best to test without that setting.

External debug info contains a checksum, and can be in diff locations. If there is an old file left, and that has the wrong checksum, then that can cause issues (and not sure if it will do the same in gdb).

"Project Options" -> "Compiler Options" -> Debugging: "Use external debug ... -Xg"

--EDIT: Actually, if you have blue dots, then it was read, and it works with the external.
    Leaves: Color and Symbol on the non working breakpoints.