ANNOUNCEMENT

"tclmsgque" is the project to integrate *PLMK* into *Tcl*.
Together with C, C++, Java, Ruby and Python, a growing language community is emerging that will combine *all* existing
programming languages with *PLMK* technology in the future.

: http://thedev.nhi1.de/NHI1/main/

“tclmsgque::MkKernel” extends *Tcl* with a “code integrator” so that a 3rd party library can be connected to *Tcl* without
additional programming effort.

: http://thedev.nhi1.de/theKernel/main/index.htm

“tclmsgque::MqMsgque” extends *Tcl* with a “code parallelizer” so that existing *Tcl* code can be parallelized and integrated
into a multiprocessor environment.

: http://thedev.nhi1.de/theLink/main/index.htm

PERFORMANCE
-----------

*Tcl* is still far behind, even the new *Ruby* is faster.

: http://thedev.nhi1.de/theLink/main/md_docs_2main_2README__PERFORMANCE.htm#README_PERFORMANCE

The reason for the performance problem with *Tcl* is still the same:

1. The "thread" support has an performance "problem" (R=with thread, A=without thread)

| send send send send create create data data
| NOTHING END CALLBACK WAIT PARENT CHILD BUS BFL
| -------- -------- -------- -------- --------- -------- -------- --------

R: Tcl | 332380 190834 120565 61112 132 23589 43077 42926
A: Tcl | 427613 247405 137936 70103 132 24716 48329 47938

Ruby and Python both support threads in the language kernel by default and it seems to be working

R: Python | 493313 315040 160869 75802 103 21982 68504 65800
R: Ruby | 436564 301587 165921 77032 52 16330 71040 63967

2. Tcl "OO" support seems to be "far behind" Ruby and Python in terms of performance.

TCL GOOD NEWS
-------------

1. My own "OO" support (called "MYOO") that I use in the new "ALC backend" code really brings a performance boost.
> nobody seems to have noticed that Tcl already had "OO" support from the beginning with the "namespace" and the
"array" function.
I think I will use the "MYOO" support in the new "aggressive-tcl" distribution as well to finally surpass "Python"
and "Ruby".

2. The "Ruby" also has a "problem" -> read below.
: http://thedev.nhi1.de/NHI1/main/RUBY.htm

occasional updates to the project are available as screenshots on social media.

: Facebook -> https://www.facebook.com/profile.php?id=100069563501101

On 11/2/24 16:14, aotto1968 wrote:
> ANNOUNCEMENT
>
> "tclmsgque" is the project to integrate *PLMK* into *Tcl*.
> Together with C, C++, Java, Ruby and Python, a growing language
> community is emerging that will combine *all* existing programming
> languages with *PLMK* technology in the future.
>
> : http://thedev.nhi1.de/NHI1/main/
>
> “tclmsgque::MkKernel” extends *Tcl* with a “code integrator” so that a
> 3rd party library can be connected to *Tcl* without additional
> programming effort.
>
> : http://thedev.nhi1.de/theKernel/main/index.htm
>
> “tclmsgque::MqMsgque” extends *Tcl* with a “code parallelizer” so that
> existing *Tcl* code can be parallelized and integrated into a
> multiprocessor environment.
>
> : http://thedev.nhi1.de/theLink/main/index.htm
>
>
> PERFORMANCE
> -----------
>
> *Tcl* is still far behind, even the new *Ruby* is faster.
>
> :
> http://thedev.nhi1.de/theLink/main/md_docs_2main_2README__PERFORMANCE.htm#README_PERFORMANCE
>
> The reason for the performance problem with *Tcl* is still the same:
>
> 1. The "thread" support has an performance "problem" (R=with thread,
> A=without thread)
>
>             |   send     send     send     send    create    create
> data     data
>             |  NOTHING   END    CALLBACK   WAIT    PARENT    CHILD
> BUS      BFL
>             | -------- -------- -------- -------- --------- --------
> -------- --------
>
>  R: Tcl     |   332380   190834   120565    61112      132    23589
> 43077    42926
>  A: Tcl     |   427613   247405   137936    70103      132    24716
> 48329    47938
>
>   Ruby and Python both support threads in the language kernel by
> default and it seems to be working
>
>  R: Python  |   493313   315040   160869    75802      103    21982
> 68504    65800
>  R: Ruby    |   436564   301587   165921    77032       52    16330
> 71040    63967

You do realize comparing Tcl with "thread" support and Python/Ruby with
their "thread" support is comparing apples to potatoes.

Tcl threads are apartment model where Python/Ruby are a shared memory
model. Tcl threads are "heavier" but easier to program and debug since
it is very hard to make them step on themselves -- something that is
ridiculously easier to do by accident in the other languages.

On 02.11.24 22:52, Gerald Lester wrote:
>> *Tcl* is still far behind, even the new *Ruby* is faster.
>>
>> : http://thedev.nhi1.de/theLink/main/md_docs_2main_2README__PERFORMANCE.htm#README_PERFORMANCE
>>
>> The reason for the performance problem with *Tcl* is still the same:
>>
>> 1. The "thread" support has an performance "problem" (R=with thread, A=without thread)
>>
>>              |   send     send     send     send    create    create data     data
>>              |  NOTHING   END    CALLBACK   WAIT    PARENT    CHILD BUS      BFL
>>              | -------- -------- -------- -------- --------- -------- -------- --------
>>
>>   R: Tcl     |   332380   190834   120565    61112      132    23589 43077    42926
>>   A: Tcl     |   427613   247405   137936    70103      132    24716 48329    47938
>>
>>    Ruby and Python both support threads in the language kernel by default and it seems to be working
>>
>>   R: Python  |   493313   315040   160869    75802      103    21982 68504    65800
>>   R: Ruby    |   436564   301587   165921    77032       52    16330 71040    63967
>
> You do realize comparing Tcl with "thread" support and Python/Ruby with their "thread" support is comparing apples to potatoes.
>
> Tcl threads are apartment model where Python/Ruby are a shared memory model.  Tcl threads are "heavier" but easier to program
> and debug since it is very hard to make them step on themselves -- something that is ridiculously easier to do by accident in
> the other languages.

just to be clear the tests itself does *not* using any kind of *thread* related feature …

| I just say that an thread-enabled-tcl is much slower than Py/Rb *but* beside the *thread*
| support the tcl OO model seems to an additional problem.

if I add the "MYOO" into the PMLK kernel than we really see if the tcl "thread" or the tcl "oo" is
the key problem.

On 02.11.24 23:42, aotto1968 wrote:
> On 02.11.24 22:52, Gerald Lester wrote:
>>> *Tcl* is still far behind, even the new *Ruby* is faster.
>>>
>>> : http://thedev.nhi1.de/theLink/main/md_docs_2main_2README__PERFORMANCE.htm#README_PERFORMANCE
>>>
>>> The reason for the performance problem with *Tcl* is still the same:
>>>
>>> 1. The "thread" support has an performance "problem" (R=with thread, A=without thread)
>>>
>>>              |   send     send     send     send    create    create data     data
>>>              |  NOTHING   END    CALLBACK   WAIT    PARENT    CHILD BUS      BFL
>>>              | -------- -------- -------- -------- --------- -------- -------- --------
>>>
>>>   R: Tcl     |   332380   190834   120565    61112      132    23589 43077    42926
>>>   A: Tcl     |   427613   247405   137936    70103      132    24716 48329    47938
>>>
>>>    Ruby and Python both support threads in the language kernel by default and it seems to be working
>>>
>>>   R: Python  |   493313   315040   160869    75802      103    21982 68504    65800
>>>   R: Ruby    |   436564   301587   165921    77032       52    16330 71040    63967
>>
>> You do realize comparing Tcl with "thread" support and Python/Ruby with their "thread" support is comparing apples to potatoes.
>>
>> Tcl threads are apartment model where Python/Ruby are a shared memory model.  Tcl threads are "heavier" but easier to program
>> and debug since it is very hard to make them step on themselves -- something that is ridiculously easier to do by accident in
>> the other languages.
>
> just to be clear the tests itself does *not* using any kind of *thread* related feature …
>
> | I just say that an thread-enabled-tcl is much slower than Py/Rb *but* beside the *thread*
> | support the tcl OO model seems to an additional problem.
>
> if I add the "MYOO" into the PMLK kernel than we really see if the tcl "thread" or the tcl "oo" is
> the key problem.

Just an other "hint" that tcl-oo is the "key" problem are the both last columns.

BUS → is a object filled in a serialized manner with data (internal build ob an continuous memory block of data)
BUF → is a object like an "c-array" filled with independent objects (internal an array of object-pointers)

as you see in RB and PY the BUS is significant faster than BFL, because the BUS just deal with ONE object.
*but* if you look to *tcl* there is *no* change between *BFL* and *BUS*

-> this is a CLEAR SIGN that the tcl-oo "overhead" eats all the performance and NOT the thread.

On 11/2/24 17:56, aotto1968 wrote:
> On 02.11.24 23:42, aotto1968 wrote:
>> On 02.11.24 22:52, Gerald Lester wrote:
>>>> *Tcl* is still far behind, even the new *Ruby* is faster.
>>>>
>>>> :
>>>> http://thedev.nhi1.de/theLink/main/md_docs_2main_2README__PERFORMANCE.htm#README_PERFORMANCE
>>>>
>>>> The reason for the performance problem with *Tcl* is still the same:
>>>>
>>>> 1. The "thread" support has an performance "problem" (R=with thread,
>>>> A=without thread)
>>>>
>>>>              |   send     send     send     send    create    create
>>>> data     data
>>>>              |  NOTHING   END    CALLBACK   WAIT    PARENT    CHILD
>>>> BUS      BFL
>>>>              | -------- -------- -------- -------- ---------
>>>> -------- -------- --------
>>>>
>>>>   R: Tcl     |   332380   190834   120565    61112      132    23589
>>>> 43077    42926
>>>>   A: Tcl     |   427613   247405   137936    70103      132    24716
>>>> 48329    47938
>>>>
>>>>    Ruby and Python both support threads in the language kernel by
>>>> default and it seems to be working
>>>>
>>>>   R: Python  |   493313   315040   160869    75802      103    21982
>>>> 68504    65800
>>>>   R: Ruby    |   436564   301587   165921    77032       52    16330
>>>> 71040    63967
>>>
>>> You do realize comparing Tcl with "thread" support and Python/Ruby
>>> with their "thread" support is comparing apples to potatoes.
>>>
>>> Tcl threads are apartment model where Python/Ruby are a shared memory
>>> model.  Tcl threads are "heavier" but easier to program and debug
>>> since it is very hard to make them step on themselves -- something
>>> that is ridiculously easier to do by accident in the other languages.
>>
>> just to be clear the tests itself does *not* using any kind of
>> *thread* related feature …
>>
>> | I just say that an thread-enabled-tcl is much slower than Py/Rb
>> *but* beside the *thread*
>> | support the tcl OO model seems to an additional problem.
>>
>> if I add the "MYOO" into the PMLK kernel than we really see if the tcl
>> "thread" or the tcl "oo" is
>> the key problem.
>
> Just an other "hint" that tcl-oo is the "key" problem are the both last
> columns.
>
> BUS → is a object filled in a serialized manner with data (internal
> build ob an continuous memory block of data)
> BUF → is a object like an "c-array" filled with independent objects
> (internal an array of object-pointers)
>
> as you see in RB and PY the BUS is significant faster than BFL, because
> the BUS just deal with ONE object.
> *but* if you look to *tcl* there is *no* change between *BFL* and *BUS*
>
> -> this is a CLEAR SIGN that the tcl-oo "overhead" eats all the
> performance and NOT the thread.

OO is not the most popular feature for many reasons.

Nice bug test by TEST.suite - C, JAVA and TCL work together like ONE single application.

->
https://www.facebook.com/permalink.php?story_fbid=pfbid0ve6DHeZdG2sLx7KiMDf4x97YKcEHvqqE13AftGZ2agKPdrreKVvjbNf34JqYEeCal&id=100069563501101