[ANN] (preview) “tclmsgque” is the connection between Tcl and the “Programming Language Microkernel” (PLMK).

[aotto1968]

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

[Gerald Lester]

Post by aotto1968
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
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.

[aotto1968]

Post by aotto1968
*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
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.

[aotto1968]

Post by aotto1968

Post by aotto1968
*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
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.

[Gerald Lester]

Post by aotto1968

Post by aotto1968

Post by Gerald Lester

Post by aotto1968
*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
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.

[aotto1968]

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