I just released a released table_sort.f and table_test.f to test and sort multiple tables.
See https://github.com/Jos-Ven/cforth/tree/WIP/src/app/esp for a download.

Gforth under Linux and Win32Forth under w11 are able to sort different tables parallel.

A test with table_test.f shows the following results (using 2 keys):

\ Under a 64 bits gforth-fast version 0.7.9_20220713
\ on the "Bookworm" with an i5-4200U CPU @ 1.60GHz I get:
Sorting 4 tables one at the time  
Needed sort time for each table with 200000 records in each table
719 679 687 697 ms READY!
Total time: 2782 ms  
1:sorted 2:sorted 3:sorted 4:sorted  

Parallel sorting 4 tables in the background moment:  
>>> Hit a key when the NEXT sort below is ready:
Needed sort time for each table with 200000 records in each table
1451 1462 1480 1469 ms READY!
Total needed time: 1481 ms  
1:sorted 2:sorted 3:sorted 4:sorted  

Changing 1 record in table1 and sorting again....
Parallel sorting 4 tables in the background moment:  

Needed sort time for each table with 200000 records in each table
443 449 443 451 ms READY!
Total needed time: 453 ms  
1:sorted 2:sorted 3:sorted 4:sorted
--------------------------

Under Win32Forth on W11 with an i9-12900 CPU @ 5.1 GHz I get:
Sorting 4 tables one at the time
Needed sort time for each table with 200000 records in each table
544 582 553 560 ms READY!
Total time: 2239 ms
1:sorted 2:sorted 3:sorted 4:sorted

Parallel sorting 4 tables in the background moment:
>>> Hit a key when the NEXT sort below is ready:
Needed sort time for each table with 200000 records in each table
566 554 545 589 ms READY!
Total needed time: 592 ms
1:sorted 2:sorted 3:sorted 4:sorted

Changing 1 record in table1 and sorting again....
Parallel sorting 4 tables in the background moment:

Needed sort time for each table with 200000 records in each table
122 120 118 119 ms READY!
Total needed time: 127 ms
1:sorted 2:sorted 3:sorted 4:sorted

Jos

Jos Ven schrieb am Freitag, 30. Juni 2023 um 12:30:57 UTC+2:
> I just released a released table_sort.f and table_test.f to test and sort multiple tables.
> See https://github.com/Jos-Ven/cforth/tree/WIP/src/app/esp for a download.
>
> Gforth under Linux and Win32Forth under w11 are able to sort different tables parallel.
>
> A test with table_test.f shows the following results (using 2 keys):
>
> \ Under a 64 bits gforth-fast version 0.7.9_20220713
> \ on the "Bookworm" with an i5-4200U CPU @ 1.60GHz I get:
> Sorting 4 tables one at the time
> Needed sort time for each table with 200000 records in each table
> 719 679 687 697 ms READY!
> Total time: 2782 ms
> 1:sorted 2:sorted 3:sorted 4:sorted
>
> Parallel sorting 4 tables in the background moment:
> >>> Hit a key when the NEXT sort below is ready:
> Needed sort time for each table with 200000 records in each table
> 1451 1462 1480 1469 ms READY!
> Total needed time: 1481 ms
> 1:sorted 2:sorted 3:sorted 4:sorted
>
> Changing 1 record in table1 and sorting again....
> Parallel sorting 4 tables in the background moment:
>
> Needed sort time for each table with 200000 records in each table
> 443 449 443 451 ms READY!
> Total needed time: 453 ms
> 1:sorted 2:sorted 3:sorted 4:sorted
> --------------------------
>
> Under Win32Forth on W11 with an i9-12900 CPU @ 5.1 GHz I get:
> Sorting 4 tables one at the time
> Needed sort time for each table with 200000 records in each table
> 544 582 553 560 ms READY!
> Total time: 2239 ms
> 1:sorted 2:sorted 3:sorted 4:sorted
>
> Parallel sorting 4 tables in the background moment:
> >>> Hit a key when the NEXT sort below is ready:
> Needed sort time for each table with 200000 records in each table
> 566 554 545 589 ms READY!
> Total needed time: 592 ms
> 1:sorted 2:sorted 3:sorted 4:sorted
>
> Changing 1 record in table1 and sorting again....
> Parallel sorting 4 tables in the background moment:
>
> Needed sort time for each table with 200000 records in each table
> 122 120 118 119 ms READY!
> Total needed time: 127 ms
> 1:sorted 2:sorted 3:sorted 4:sorted
>
> Jos

Nice and well, but what does it tell us? That the i9 is faster?

Op vrijdag 30 juni 2023 om 12:57:22 UTC+2 schreef minforth:
> Jos Ven schrieb am Freitag, 30. Juni 2023 um 12:30:57 UTC+2:
> > I just released a released table_sort.f and table_test.f to test and sort multiple tables.
> > See https://github.com/Jos-Ven/cforth/tree/WIP/src/app/esp for a download.
> >
> > Gforth under Linux and Win32Forth under w11 are able to sort different tables parallel.
> >
> > A test with table_test.f shows the following results (using 2 keys):
> >
> > \ Under a 64 bits gforth-fast version 0.7.9_20220713
> > \ on the "Bookworm" with an i5-4200U CPU @ 1.60GHz I get:
> > Sorting 4 tables one at the time
> > Needed sort time for each table with 200000 records in each table
> > 719 679 687 697 ms READY!
> > Total time: 2782 ms
> > 1:sorted 2:sorted 3:sorted 4:sorted
> >
> > Parallel sorting 4 tables in the background moment:
> > >>> Hit a key when the NEXT sort below is ready:
> > Needed sort time for each table with 200000 records in each table
> > 1451 1462 1480 1469 ms READY!
> > Total needed time: 1481 ms
> > 1:sorted 2:sorted 3:sorted 4:sorted
> >
> > Changing 1 record in table1 and sorting again....
> > Parallel sorting 4 tables in the background moment:
> >
> > Needed sort time for each table with 200000 records in each table
> > 443 449 443 451 ms READY!
> > Total needed time: 453 ms
> > 1:sorted 2:sorted 3:sorted 4:sorted
> > --------------------------
> >
> > Under Win32Forth on W11 with an i9-12900 CPU @ 5.1 GHz I get:
> > Sorting 4 tables one at the time
> > Needed sort time for each table with 200000 records in each table
> > 544 582 553 560 ms READY!
> > Total time: 2239 ms
> > 1:sorted 2:sorted 3:sorted 4:sorted
> >
> > Parallel sorting 4 tables in the background moment:
> > >>> Hit a key when the NEXT sort below is ready:
> > Needed sort time for each table with 200000 records in each table
> > 566 554 545 589 ms READY!
> > Total needed time: 592 ms
> > 1:sorted 2:sorted 3:sorted 4:sorted
> >
> > Changing 1 record in table1 and sorting again....
> > Parallel sorting 4 tables in the background moment:
> >
> > Needed sort time for each table with 200000 records in each table
> > 122 120 118 119 ms READY!
> > Total needed time: 127 ms
> > 1:sorted 2:sorted 3:sorted 4:sorted
> >
> > Jos

Hi,
> Nice and well, but what does it tell us? That the i9 is faster?
It tells me the following:
1) It indeed works under Gforth and Win32Forth
2) It does not have to take much time more to sort 4 table instead of 1 table.
3) If you change only 1 record than a new sort is much faster.

I did this since my old sorting source made me write unclear code when multiple tables are used.

Jos

Jos Ven schrieb am Freitag, 30. Juni 2023 um 13:51:36 UTC+2:
> Op vrijdag 30 juni 2023 om 12:57:22 UTC+2 schreef minforth:
> > Jos Ven schrieb am Freitag, 30. Juni 2023 um 12:30:57 UTC+2:
> > > I just released a released table_sort.f and table_test.f to test and sort multiple tables.
> > > See https://github.com/Jos-Ven/cforth/tree/WIP/src/app/esp for a download.
> > >
> > > Gforth under Linux and Win32Forth under w11 are able to sort different tables parallel.
> > >
> > > A test with table_test.f shows the following results (using 2 keys):
> > >
> > > \ Under a 64 bits gforth-fast version 0.7.9_20220713
> > > \ on the "Bookworm" with an i5-4200U CPU @ 1.60GHz I get:
> > > Sorting 4 tables one at the time
> > > Needed sort time for each table with 200000 records in each table
> > > 719 679 687 697 ms READY!
> > > Total time: 2782 ms
> > > 1:sorted 2:sorted 3:sorted 4:sorted
> > >
> > > Parallel sorting 4 tables in the background moment:
> > > >>> Hit a key when the NEXT sort below is ready:
> > > Needed sort time for each table with 200000 records in each table
> > > 1451 1462 1480 1469 ms READY!
> > > Total needed time: 1481 ms
> > > 1:sorted 2:sorted 3:sorted 4:sorted
> > >
> > > Changing 1 record in table1 and sorting again....
> > > Parallel sorting 4 tables in the background moment:
> > >
> > > Needed sort time for each table with 200000 records in each table
> > > 443 449 443 451 ms READY!
> > > Total needed time: 453 ms
> > > 1:sorted 2:sorted 3:sorted 4:sorted
> > > --------------------------
> > >
> > > Under Win32Forth on W11 with an i9-12900 CPU @ 5.1 GHz I get:
> > > Sorting 4 tables one at the time
> > > Needed sort time for each table with 200000 records in each table
> > > 544 582 553 560 ms READY!
> > > Total time: 2239 ms
> > > 1:sorted 2:sorted 3:sorted 4:sorted
> > >
> > > Parallel sorting 4 tables in the background moment:
> > > >>> Hit a key when the NEXT sort below is ready:
> > > Needed sort time for each table with 200000 records in each table
> > > 566 554 545 589 ms READY!
> > > Total needed time: 592 ms
> > > 1:sorted 2:sorted 3:sorted 4:sorted
> > >
> > > Changing 1 record in table1 and sorting again....
> > > Parallel sorting 4 tables in the background moment:
> > >
> > > Needed sort time for each table with 200000 records in each table
> > > 122 120 118 119 ms READY!
> > > Total needed time: 127 ms
> > > 1:sorted 2:sorted 3:sorted 4:sorted
> > >
> > > Jos
> Hi,
> > Nice and well, but what does it tell us? That the i9 is faster?
> It tells me the following:
> 1) It indeed works under Gforth and Win32Forth
> 2) It does not have to take much time more to sort 4 table instead of 1 table.
> 3) If you change only 1 record than a new sort is much faster.
>
> I did this since my old sorting source made me write unclear code when multiple tables are used.
>

Just out of curiosity and with due respect for your work:
Since cforth is C-based and since qsort is in stdlib anyway, did you
compare your shell-sort against qsort?
(assuming that in both versions only the index array is sorted in memory)

Op vrijdag 30 juni 2023 om 14:06:05 UTC+2 schreef minforth:
> Jos Ven schrieb am Freitag, 30. Juni 2023 um 13:51:36 UTC+2:
> > Op vrijdag 30 juni 2023 om 12:57:22 UTC+2 schreef minforth:
> > > Jos Ven schrieb am Freitag, 30. Juni 2023 um 12:30:57 UTC+2:
> > > > I just released a released table_sort.f and table_test.f to test and sort multiple tables.
> > > > See https://github.com/Jos-Ven/cforth/tree/WIP/src/app/esp for a download.
> > > >
> > > > Gforth under Linux and Win32Forth under w11 are able to sort different tables parallel.
> > > >
> > > > A test with table_test.f shows the following results (using 2 keys):
> > > >
> > > > \ Under a 64 bits gforth-fast version 0.7.9_20220713
> > > > \ on the "Bookworm" with an i5-4200U CPU @ 1.60GHz I get:
> > > > Sorting 4 tables one at the time
> > > > Needed sort time for each table with 200000 records in each table
> > > > 719 679 687 697 ms READY!
> > > > Total time: 2782 ms
> > > > 1:sorted 2:sorted 3:sorted 4:sorted
> > > >
> > > > Parallel sorting 4 tables in the background moment:
> > > > >>> Hit a key when the NEXT sort below is ready:
> > > > Needed sort time for each table with 200000 records in each table
> > > > 1451 1462 1480 1469 ms READY!
> > > > Total needed time: 1481 ms
> > > > 1:sorted 2:sorted 3:sorted 4:sorted
> > > >
> > > > Changing 1 record in table1 and sorting again....
> > > > Parallel sorting 4 tables in the background moment:
> > > >
> > > > Needed sort time for each table with 200000 records in each table
> > > > 443 449 443 451 ms READY!
> > > > Total needed time: 453 ms
> > > > 1:sorted 2:sorted 3:sorted 4:sorted
> > > > --------------------------
> > > >
> > > > Under Win32Forth on W11 with an i9-12900 CPU @ 5.1 GHz I get:
> > > > Sorting 4 tables one at the time
> > > > Needed sort time for each table with 200000 records in each table
> > > > 544 582 553 560 ms READY!
> > > > Total time: 2239 ms
> > > > 1:sorted 2:sorted 3:sorted 4:sorted
> > > >
> > > > Parallel sorting 4 tables in the background moment:
> > > > >>> Hit a key when the NEXT sort below is ready:
> > > > Needed sort time for each table with 200000 records in each table
> > > > 566 554 545 589 ms READY!
> > > > Total needed time: 592 ms
> > > > 1:sorted 2:sorted 3:sorted 4:sorted
> > > >
> > > > Changing 1 record in table1 and sorting again....
> > > > Parallel sorting 4 tables in the background moment:
> > > >
> > > > Needed sort time for each table with 200000 records in each table
> > > > 122 120 118 119 ms READY!
> > > > Total needed time: 127 ms
> > > > 1:sorted 2:sorted 3:sorted 4:sorted
> > > >
> > > > Jos
> > Hi,
> > > Nice and well, but what does it tell us? That the i9 is faster?
> > It tells me the following:
> > 1) It indeed works under Gforth and Win32Forth
> > 2) It does not have to take much time more to sort 4 table instead of 1 table.
> > 3) If you change only 1 record than a new sort is much faster.
> >
> > I did this since my old sorting source made me write unclear code when multiple tables are used.
> >
> Just out of curiosity and with due respect for your work:
> Since cforth is C-based and since qsort is in stdlib anyway, did you
> compare your shell-sort against qsort?
> (assuming that in both versions only the index array is sorted in memory)

Hi, Thank you for all the comments.
The qsort in stdlib looks like a rudimentary source for only one key.
Also not sure if it that would allow me to use multiple tables in a clear way in Forth.

Jos

Jos Ven schrieb am Freitag, 30. Juni 2023 um 15:22:26 UTC+2:
> Hi, Thank you for all the comments.
> The qsort in stdlib looks like a rudimentary source for only one key.
> Also not sure if it that would allow me to use multiple tables in a clear way in Forth.

off-topic:
the qsort api is as simple as can be of course. handling a small number of multi-keys
can done by the comparator function, but this can become rather unflexibe indeed.
and keys in global variables can mean to lose reentrancy.

but when you have your own forth source, you ride in the saddle :)

In article <97ad0c53-7e7c-4d47-8c01-49062c785525n@googlegroups.com>,
Jos Ven <josv@planet.nl> wrote:
>I just released a released table_sort.f and table_test.f to test and
>sort multiple tables.
>See https://github.com/Jos-Ven/cforth/tree/WIP/src/app/esp for a download.
>
>Gforth under Linux and Win32Forth under w11 are able to sort different
>tables parallel.

Can you explain what you mean by sorting "multiple tables" "parallel"?
Is it fair to say:
cforth has the ability to perform Forth code in parallel,
this makes sense provided *you have multiple cores*
You have made a sort that is re-entrant. That is, it can actually run
in parallel without disturbing the other sort's.

>Jos
Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

Op zaterdag 1 juli 2023 om 11:39:00 UTC+2 schreef none albert:
> In article <9...om>,
> J..nl> wrote:
> >I just released a released table_sort.f and table_test.f to test and
> >sort multiple tables.
> >See https://github.com/Jos-Ven/cforth/tree/WIP/src/app/esp for a download.
> >
> >Gforth under Linux and Win32Forth under w11 are able to sort different
> >tables parallel.
> Can you explain what you mean by sorting "multiple tables" "parallel"?
> Is it fair to say:
> cforth has the ability to perform Forth code in parallel,
> this makes sense provided *you have multiple cores*
> You have made a sort that is re-entrant. That is, it can actually run
> in parallel without disturbing the other sort's.
>
> >Jos
> Albert
> --
> Don't praise the day before the evening. One swallow doesn't make spring.
> You must not say "hey" before you have crossed the bridge. Don't sell the
> hide of the bear until you shot it. Better one bird in the hand than ten in
> the air. First gain is a cat spinning. - the Wise from Antrim -

Hi,
That is right for Gforth and Win32Forth and perhaps other Forth-systems that are able
to use preemptive multitasking on a CPU with multiple cores.
The problem with Cforth on an ESP32 is that it does not yet use multiple cores.

Jos

On Saturday, July 1, 2023 at 12:26:40 PM UTC+2, Jos Ven wrote:
> Op zaterdag 1 juli 2023 om 11:39:00 UTC+2 schreef none albert:
> > In article <9...om>,
> > J..nl> wrote:
> > >I just released a released table_sort.f and table_test.f to test and
> > >sort multiple tables.
> > >See https://github.com/Jos-Ven/cforth/tree/WIP/src/app/esp for a download.

What happens if you (accidentally) specify tables that are actually the same? Like,
'sort db1 on column 1; sort db2 on column 2; sort db2 on column 3;
sort db1 on column 4; ' ?

-marcel

Op zaterdag 1 juli 2023 om 18:51:12 UTC+2 schreef Marcel Hendrix:
> On Saturday, July 1, 2023 at 12:26:40 PM UTC+2, Jos Ven wrote:
> > Op zaterdag 1 juli 2023 om 11:39:00 UTC+2 schreef none albert:
> > > In article <9...om>,
> > > J..nl> wrote:
> > > >I just released a released table_sort.f and table_test.f to test and
> > > >sort multiple tables.
> > > >See https://github.com/Jos-Ven/cforth/tree/WIP/src/app/esp for a download.
> What happens if you (accidentally) specify tables that are actually the same? Like,
> 'sort db1 on column 1; sort db2 on column 2; sort db2 on column 3;
> sort db1 on column 4; ' ?
>
> -marcel

Hi,
Thanks to your example I understand the following:
The problem is not the same size of the tables, but sorting
1 table 2 times parallel and using different 2 keys at the same time.
I tried it as follows:

: sort-test ( &table -- ) \ for table3 an table4
>r by[ test-chars test-group ]by r> table-sort ;

: sort-test1 ( &table -- ) \ for table1
>r by[ test-group ]by r> table-sort ;

: sort-test2 ( &table -- ) \ for table1
>r by[ test-chars ]by r> table-sort ;

Then table1 and again table1 table3 and table4 were parallel sorted.
Here is how is output looks for 10 records:

&table1 .records-sorted
0 fniocxww 1
1 hnlvpkkq 2
2 hvmfxkbe 1
3 jrvsrbwg 2
4 mlxxmvid 0
5 ofpdhmfp 0
6 ookrjluc 1
7 uujgmwhm 2
8 xryzcqzg 0
9 zbdnykzm 2 ok

&table3 .records-sorted
0 dkifbmmi 0
1 edrpmouy 0
2 obhayoqn 0
3 aldnvmes 1
4 junhlfwg 1
5 laitxzyr 1
6 zhxvkxat 1
7 ivslidzz 2
8 kztelryf 2
9 psgsdhji 2 ok

&table4 .records-sorted
0 gmxqrwzf 0
1 gorzpygj 0
2 jwstyqps 0
3 bmmfvocw 1
4 uaaioquq 1
5 fslktexz 2
6 mexkqbrq 2
7 rabcemhq 2
8 sxjfqiod 2
9 thuhxqjy 2 ok

Table1 got garbadge in so you get garbadge out.
tables3 and table4 are OK
Jos