On 8/18/2024 1:42 PM, aotto1968 wrote:
>
> add some documentation regarding the performance testing:
> -> http://thedev.nhi1.de/theLink/main/md_docs_2main_2README__PERFORMANCE.htm

I recently wrote some C code using Visual Studio 2022 and they have a wonderful performance profiler. I was able to determine that 80% of the cost of the module I was developing was caused by calls to some library routines I was using. By writing my own versions that didn't need to be so generalized, I got that down to 10%.

One problem was that once I turned on the compiler optimization, the profiler became pretty much worthless to measure my own code's performance, so I couldn't get that 10% any lower.

But it would be kinda cool to try using those VS tools on the tcl source code, but I don't know of any way to build tcl inside VS where one could use those tools.

On 19.08.24 00:29, et99 wrote:
> On 8/18/2024 1:42 PM, aotto1968 wrote:
>>
>> add some documentation regarding the performance testing:
>> -> http://thedev.nhi1.de/theLink/main/md_docs_2main_2README__PERFORMANCE.htm
>
>
> I recently wrote some C code using Visual Studio 2022 and they have a wonderful performance profiler. I was able to determine
> that 80% of the cost of the module I was developing was caused by calls to some library routines I was using. By writing my own
> versions that didn't need to be so generalized, I got that down to 10%.
>
> One problem was that once I turned on the compiler optimization, the profiler became pretty much worthless to measure my own
> code's performance, so I couldn't get that 10% any lower.
>
> But it would be kinda cool to try using those VS tools on the tcl source code, but I don't know of any way to build tcl inside
> VS where one could use those tools.
>

With the callgrind tool on linux you can analyze any kind of executable, even executable's without symbols compiled in.

Enclosed you will find an update of the results of the performance test, with a focus on the description of the tools, tests and
the analysis of the results.

-> http://thedev.nhi1.de/theLink/main/md_docs_2main_2README__PERFORMANCE.htm#performance-server

Now it's that time again and I've put a small C++ project in between to slowly but surely make better use of the "kernel" via
the C++ compiler (and some features like templates etc.).

-> http://thedev.nhi1.de/NHI1/main/index.htm

The performance code has been revised again and the unnecessary TCP tests are placed behind the UDS tests. With the C++ "agile"
kernel, C++ is now on a par with C, while using a much more user-friendly programming interface.

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

Also important, the ALC (All-Language Compiler) compiler was written in TCL.

short update

When adding the new option "__parser__(null-allowed)" I now get a nice (but still incorrect) error message. It is important to
note, however, that I can see the stack trace across TCL and C code. In fact, the Programming Language Micro Kernel (PLMK) does
not care which target language is involved.

https://www.facebook.com/permalink.php?story_fbid=pfbid0275qjybHm1Fk2iyvkwGhypQ3hgxnMH6V9HcpZxtRDXzxBW8TRxVVPG42ogDThxgGFl&id=100069563501101

Down is the "C" code of the C-Function to test the an "object" to be valid.

1. in "python"

bool MK(TestObject) (
PyObject * pyO,
PyTypeObject * typeO,
MK_OBJ * objP,
MkTestClassE * flagP
) {
MkTestClassE flag = MkTestClassE_NONE_OBJECT;
MK_OBJ obj = NULL;
if (pyO == Py_None) {
flag=MkTestClassE_NULL; goto end;
}
if (!PyObject_TypeCheck(pyO,typeO)) {
flag=MkTestClassE_WRONG_CLASS; goto end;
}
MK_MNG objM = VAL2MNG(pyO);
if (objM == NULL) { flag=MkTestClassE_NULL ; goto end; };
obj = MkObj(objM);
if (obj == NULL) { flag=MkTestClassE_INVALID_SIGNATURE ; goto end; };
flag = MkTestClassE_OK;
end:
if (flagP) *flagP = flag;
if (objP) *objP = obj;
switch(flag) {
case MkTestClassE_NONE_OBJECT : return false;
default : return true;
}
}

2. same in "Tcl"

( tcl "C"-Api has "no" function to test if an object has an "given" type etc. )

bool MK(TestObject) (
OT_Prefix_ARGS
Tcl_Obj * tclO,
MK_OBJ * objP,
MkTestClassE * flagP
) {
MkTestClassE flag = MkTestClassE_NONE_OBJECT;

int len=0;
MK_STRN str = Tcl_GetStringFromObj(tclO,&len);
if (len == 0 || MkStringIsNULL(MkStringCreate(len,str))) {
flag=MkTestClassE_NULL; goto end;
}

Tcl_Object tclObj = Tcl_GetObjectFromObj (interp, tclO);
if (tclObj == NULL) {
Tcl_ResetResult(interp);
flag=MkTestClassE_NONE_OBJECT; goto end;
};

objM = Tcl_ObjectGetMetadata(tclObj, &MK(AtomMeta));
/* NULL or wrong class etc */
if (objM == NULL) { flag=MkTestClassE_NULL ; goto end; };

objM = MkObj(objM);
if (objM == NULL) { flag=MkTestClassE_INVALID_SIGNATURE ; goto end; };

flag = MkTestClassE_OK;
if (objP) *objP = objM;

end:
if (flagP) *flagP = flag;
switch(flag) {
case MkTestClassE_NONE_OBJECT : return false;
default : return true;
}
}

On 9/6/24 22:36, aotto1968 wrote:

> Down is the "C" code of the C-Function to test the an "object" to be valid.
> ...

Hmm, to judge the "efficiently" of the tcl "c" api is between difficult
and impossible due to your "cryptically" "c" code snippets. In other
words, more context would be of tremendous help. So where is the beef?
Or ham, or even spam?

On 9/8/24 08:04, undroidwish wrote:
> On 9/6/24 22:36, aotto1968 wrote:
>
>> Down is the "C" code of the C-Function to test the an "object" to be
>> valid.
>> ...
>
> Hmm, to judge the "efficiently" of the tcl "c" api is between difficult
> and impossible due to your "cryptically" "c" code snippets. In other
> words, more context would be of tremendous help. So where is the beef?
> Or ham, or even spam?

Others, including myself, have asked him for the Tcl and Python code he
is using to get his measurements -- he has consistently refused to
supply the code.

Long and short, to me this is just spam.

Am 08.09.24 um 15:26 schrieb Gerald Lester:
> On 9/8/24 08:04, undroidwish wrote:
>> On 9/6/24 22:36, aotto1968 wrote:
>>
>>> Down is the "C" code of the C-Function to test the an "object" to be
>>> valid.
>>> ...
>>
>> Hmm, to judge the "efficiently" of the tcl "c" api is between difficult
>> and impossible due to your "cryptically" "c" code snippets. In other
>> words, more context would be of tremendous help. So where is the beef?
>> Or ham, or even spam?
>
> Others, including myself, have asked him for the Tcl and Python code he
> is using to get his measurements -- he has consistently refused to
> supply the code.
>
> Long and short, to me this is just spam.

Also my conclusion. As far as I understand it, he has written his own
warpper generator - something like SWIG - and calls ist "universal
compiler" or similar names. His Tcl wrappers are much slower than his
Python wrappers. It seems that he creates TclOO objects in his code. I
would suggest to simply use SWIG and then talk about the performance. My
guess is that SWIG wrappers will not show any difference between Tcl and
Python (because they are not based on TclOO in Tcl, which is not
necessary to get an OO interface).

Christian

On 08.09.24 19:10, Christian Gollwitzer wrote:
>
> Also my conclusion. As far as I understand it, he has written his own warpper generator - something like SWIG - and calls ist
> "universal compiler" or similar names. His Tcl wrappers are much slower than his Python wrappers. It seems that he creates TclOO
> objects in his code. I would suggest to simply use SWIG and then talk about the performance. My guess is that SWIG wrappers will
> not show any difference between Tcl and Python (because they are not based on TclOO in Tcl, which is not necessary to get an OO
> interface).
>

SWIG is far less than ALC but you are right TCL is much slower than PYTHON in C integration. it is an "design" issue of the API
because in PY all (basic) objects are instances and these instances are defined in C. The tcl OO is like an and-on to the TCL
language and in PY it IS the PY language.

I posted the code above just to show some simple facts:
1. Tcl has no "NULL" object → "NULL" is not even defined in Tcl
2. Tcl has no C-API to get/compare a "TYPE" of an object like Py_TYPE.
3. even to get an simple pointer from an object is just a C cast in PY and a
HASH table lookup in TCL

tcl has an advantage that TCL has an usable THREAD interface BUT this thread interface "cost" ~30% performance
compared to non-thread.

On 08.09.24 15:26, Gerald Lester wrote:
> On 9/8/24 08:04, undroidwish wrote:
>> On 9/6/24 22:36, aotto1968 wrote:
>>
>>> Down is the "C" code of the C-Function to test the an "object" to be valid.
>>> ...
>>
>> Hmm, to judge the "efficiently" of the tcl "c" api is between difficult
>> and impossible due to your "cryptically" "c" code snippets. In other
>> words, more context would be of tremendous help. So where is the beef?
>> Or ham, or even spam?
>
> Others, including myself, have asked him for the Tcl and Python code he is using to get his measurements -- he has consistently
> refused to supply the code.
>
> Long and short, to me this is just spam.

I understand that the "missing-code" thing is just a kind of "self-protection" issue

→ If you make an performance check between TCL and JAVA you don't start with "analyze the JAVA kernel" etc
→ If I post a result this is the the result *AFTER* all known optimization was applied etc
→ If I write that TCL is ~30% slower as PY than it is so.
→ Even if I would send you the PLMK-kernel-code you probably will never understand this but this is no problem
because you also drive a car without "understand" the internals of a car and if I say that PORSCHE
is fasten than "VAUXHALL" than nobody will say:
-> "I don't accept this until I have checked the VAUXHALL design specs".

On 9/9/24 08:04, aotto1968 wrote:

> ...
> I posted the code above just to show some simple facts:
> 1. Tcl has no "NULL" object → "NULL" is not even defined in Tcl
> ...

I'd call this a non-argument performance and otherwise given that
even the inventor of NULL regretted this his invention, see

https://en.wikipedia.org/wiki/Tony_Hoarehttps://en.wikipedia.org/wiki/Tony_Hoare

in this quote

"I call it my billion-dollar mistake. It was the invention of the null
reference in 1965. At that time, I was designing the first comprehensive
type system for references in an object oriented language (ALGOL W). My
goal was to ensure that all use of references should be absolutely safe,
with checking performed automatically by the compiler. But I couldn't
resist the temptation to put in a null reference, simply because it was
so easy to implement. This has led to innumerable errors,
vulnerabilities, and system crashes, which have probably caused a
billion dollars of pain and damage in the last forty years."

On 09.09.24 11:11, undroidwish wrote:
> On 9/9/24 08:04, aotto1968 wrote:
>
>> ...
>> I posted the code above just to show some simple facts:
>> 1. Tcl has no "NULL" object → "NULL" is not even defined in Tcl
>> ...
>
> I'd call this a non-argument performance and otherwise given that
> even the inventor of NULL regretted this his invention, see
>
> https://en.wikipedia.org/wiki/Tony_Hoarehttps://en.wikipedia.org/wiki/Tony_Hoare
>
> in this quote
>
> "I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the
> first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of
> references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the
> temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors,
> vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years."

→ you compare "apple" with "orange"

a NULL in "C" is not the same as an "None" in python or a "null" in java
→ this guy complain about the "NULL-POINTER" mistake which crate a dump in misuse etc
→ the "NULL" I speak about is to introduce a "non existing reference" as an information which is **not**
a NULL-pointer is "C".

example: if you lookup "otto" in a database than you get a "non existing NULL" back it "otto" does not exists
TCL has *no** default "NULL" type to indicate this issue, TCL can give an empty string back like "" **but**
if the "empty string" is the real value for "otto" in the database THAN you can NOT distinguish the both cases
1) "otto" does NOT exists
2) "otto" exists BUT has the value ""

On 9/9/24 11:59, aotto1968 wrote:

>   example: if you lookup "otto" in a database than you get a "non
> existing NULL" back it "otto" does not exists
>            TCL has *no** default "NULL" type to indicate this issue,
> TCL can give an empty string back like "" **but**
>            if the "empty string" is the real value for "otto" in the
> database THAN you can NOT distinguish the both cases
>            1) "otto" does NOT exists
>            2) "otto" exists BUT has the value ""

Interesting, you're now talking about a result set, which could be
expressed as a Tcl list. An empty result set is an empty list, then.
In your lookup example a non-empty result has exactly one list element.
So where's your point?

On 09.09.24 12:08, undroidwish wrote:
> On 9/9/24 11:59, aotto1968 wrote:
>
>>    example: if you lookup "otto" in a database than you get a "non existing NULL" back it "otto" does not exists
>>             TCL has *no** default "NULL" type to indicate this issue, TCL can give an empty string back like "" **but**
>>             if the "empty string" is the real value for "otto" in the database THAN you can NOT distinguish the both cases
>>             1) "otto" does NOT exists
>>             2) "otto" exists BUT has the value ""
>
> Interesting, you're now talking about a result set, which could be
> expressed as a Tcl list. An empty result set is an empty list, then.
> In your lookup example a non-empty result has exactly one list element.
> So where's your point?

→ ok, let make is very very simple.

near every programming language have some kind of "null" object/value/etc defined,
→ do you think the whole programming world is "stupid" ?

On 9/9/24 14:30, aotto1968 wrote:

> ...
> → ok, let make is very very simple.
>
> near every programming language have some kind of "null"
> object/value/etc defined,
> → do you think the whole programming world is "stupid" ?

You gave an example of a database query, which can produce a
result set with one item or nothing. Which in my argument fits
perfectly in a representation as Tcl list.

Now you seem to complain, that the Tcl paradigm does not have
a NULL thing. Which depending on context could well be an
empty list, as I've tried to explain, BTW.

And let me be clear: my thoughts about the whole programming
world were not part of the discussion.

So I interpret your last posting as pure trolling.

Congratulation, you have qualified for my ignore list. Good riddance!

To give some substance to the amazement about the "performance test", I am in the process of building a "perfserver
distribution". The problem with something like this is that the files have to be extracted from the build environment and then
moved to a completely new location to "work".

https://www.facebook.com/permalink.php?story_fbid=pfbid02pHoDtBkJUrQKZqMa1JsxpC4pGLXj7J1Chx6p96idKRzXh3zQmAVFjWMbxYypYei8l&id=100069563501101

The really impressive thing about the result of the new JAVA performance test is that PYTHON (a scripting language) is on the
SAME performance level as JAVA (a compiled language). PYTHON has obviously invested heavily in performance optimization.

x86_64-suse-linux-gnu | send send send send create create data data
2024-09-11 21:27:41 | NOTHING END CALLBACK WAIT PARENT CHILD BUS BFL
------------------------- | -------- -------- -------- -------- --------- -------- -------- --------

pipe:
R: C | 530275 400403 222971 90707 3859 37965 89818 81581
R: C++ | 528852 396473 219499 89816 2470 36635 89619 89994
R: Python | 492501 304463 159169 73570 101 22109 68875 66767
R: Tcl | 306202 144504 78180 49443 81 18337 25233 25242
R: Java | 474683 313162 170157 79324 69 19772 72242 72031

x86_64-suse-linux-gnu | send send send send create create data data
2024-09-11 21:27:41 | NOTHING END CALLBACK WAIT PARENT CHILD BUS BFL
------------------------- | -------- -------- -------- -------- --------- -------- -------- --------

uds_fork:
R: C | 524971 396466 224320 89966 11814 38479 83146 90475
R: C++ | 520668 390057 216610 89014 8712 36018 89073 89726
R: Python | 494415 314163 160014 75356 344 22197 69082 67205
R: Tcl | na. na. na. na. na. na. na. na.
R: Java | na. na. na. na. na. na. na. na.

x86_64-suse-linux-gnu | send send send send create create data data
2024-09-11 21:27:41 | NOTHING END CALLBACK WAIT PARENT CHILD BUS BFL
------------------------- | -------- -------- -------- -------- --------- -------- -------- --------

uds_thread:
R: C | 504425 375809 212943 88359 32173 37978 87952 88606
R: C++ | 494135 365464 205933 88317 31582 35011 88070 73875
R: Python | na. na. na. na. na. na. na. na.
R: Tcl | 296177 139328 75300 47983 82 18166 24879 24783
R: Java | 463538 309542 161559 79059 19282 19779 72112 71591

x86_64-suse-linux-gnu | send send send send create create data data
2024-09-11 21:27:41 | NOTHING END CALLBACK WAIT PARENT CHILD BUS BFL
------------------------- | -------- -------- -------- -------- --------- -------- -------- --------

uds_spawn:
R: C | 530643 399273 228727 90660 3795 37906 89667 90450
R: C++ | 522584 389941 218076 89381 2473 36351 88390 89105
R: Python | 494427 312230 137856 70085 101 22259 68911 66719
R: Tcl | 315789 147933 79493 49956 79 17944 23599 25445
R: Java | 475697 306405 161973 79067 68 18112 67439 66953

Quick update, I removed the "--enable-symboles" from TCL in the release build and the performance has improved significantly but
it is still ~25% behind PYTHON and JAVA. Apparently "--enable-symboles" has a significant impact on performance in TCL, which is
good to know because it is often delivered with "--enable-symboles" in order to better analyze an error later during operation.

x86_64-suse-linux-gnu | send send send send create create data data
2024-09-11 21:54:55 | NOTHING END CALLBACK WAIT PARENT CHILD BUS BFL
------------------------- | -------- -------- -------- -------- --------- -------- -------- --------

pipe:
R: C | 530275 400403 222971 90707 3859 37965 89818 81581
R: C++ | 528852 396473 219499 89816 2470 36635 89619 89994
R: Python | 492501 304463 159169 73570 101 22109 68875 66767
R: Tcl | 402439 236730 127712 59048 133 24002 44337 43762
R: Java | 474683 313162 170157 79324 69 19772 72242 72031

x86_64-suse-linux-gnu | send send send send create create data data
2024-09-11 21:54:55 | NOTHING END CALLBACK WAIT PARENT CHILD BUS BFL
------------------------- | -------- -------- -------- -------- --------- -------- -------- --------

uds_fork:
R: C | 524971 396466 224320 89966 11814 38479 83146 90475
R: C++ | 520668 390057 216610 89014 8712 36018 89073 89726
R: Python | 494415 314163 160014 75356 344 22197 69082 67205
R: Tcl | na. na. na. na. na. na. na. na.
R: Java | na. na. na. na. na. na. na. na.

x86_64-suse-linux-gnu | send send send send create create data data
2024-09-11 21:54:55 | NOTHING END CALLBACK WAIT PARENT CHILD BUS BFL
------------------------- | -------- -------- -------- -------- --------- -------- -------- --------

uds_thread:
R: C | 504425 375809 212943 88359 32173 37978 87952 88606
R: C++ | 494135 365464 205933 88317 31582 35011 88070 73875
R: Python | na. na. na. na. na. na. na. na.
R: Tcl | 390334 224660 123795 63402 139 24137 44490 38410
R: Java | 463538 309542 161559 79059 19282 19779 72112 71591

x86_64-suse-linux-gnu | send send send send create create data data
2024-09-11 21:54:55 | NOTHING END CALLBACK WAIT PARENT CHILD BUS BFL
------------------------- | -------- -------- -------- -------- --------- -------- -------- --------

uds_spawn:
R: C | 530643 399273 228727 90660 3795 37906 89667 90450
R: C++ | 522584 389941 218076 89381 2473 36351 88390 89105
R: Python | 494427 312230 137856 70085 101 22259 68911 66719
R: Tcl | 402035 234600 126871 63312 134 22768 41101 39604
R: Java | 475697 306405 161973 79067 68 18112 67439 66953