Re: [Oorexx-devel] my experience with MyRexxComp.rex and MyRexxComp.ini
Franz wrote: I think I do not use the correct editor with KATE for my .ini file, it is too silly for me. I attach to you my last 2 test-files. I think you can tell me what I have to do. Your MyRexxComp.ini file was last edited and saved using UTF-8 codepage encoding. This is shown as the UTF-8 marker sequence and text handling placed by the editor at the beginning of line one of file MyRexxComp.ini: EFBBBF2F2A272A2A… ï » ¿ / * ' * * … With the editor you’re using, you will need to re-open the file, change the codepage to a straight or extended ASCII codepage, and save again. Mark ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] "Per-Interpreter GIL" will land in Python 3.12
Restated, instead of a common or mutex lock, they are now going to use a per interpreter instance lock. A long time overdue, but the author’s assertion of “truly concurrent Python code” is incorrect and should have been stated otherwise. The real implication is that when multiple Python interpreters are in use within a single process, the interpreters are no longer single threaded by the use of a common GIL (Global Interpreter Lock). In other words, they’re fixing an issue that most Python programmers don’t use directly, but is a feature used by major library routines (for example, AI). The author finally makes this admission directly in their conclusion. Mark L. Gaubatz From: Jean Louis Faucher Sent: Tuesday, May 16, 2023 07:37 To: Open Object Rexx Developer Mailing List Subject: [Oorexx-devel] "Per-Interpreter GIL" will land in Python 3.12 I saw this link in the daily TLDR mail of today: https://martinheinz.dev/blog/97 Real Multithreading is Coming to Python - Learn How You Can Use It Now Did not read in details yet, but seems worth to understand how they implemented their "Per-Interpreter GIL”. ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Ad "Sir Santa's Bag for 2022" ...
+1 from here as well as from my clients. Mark ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Error in array class with two dimensional arrays ?
Rony: Since the original version of ooRexx, without a declaration of how to view the multi-dimensional objects sparsely, results are generically indeterminate as mapping is based on the highest indices used. Thus, either an .array~new(6,7) specification is required, or the first element initialized must reference the highest indices to be used. Otherwise, the array is effectively remapped with each use. Consequently, if the first use sets element [6,7], then a specification of .array~new works properly. Mark ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] An alternative algorithm for x2c()
Two additional quick notes:
1. The static const arrays may be const only when dealing with a fixed
character set. For some products I’ve worked on, the initialization of the
arrays occurs during startup and after a character set option has been selected.
2. (len % 2 == 1), while syntactically correct, does not optimize on
several compilers for performance. The fastest all around is ((len & 1u)).
Mark
From: Mark L. Gaubatz via Oorexx-devel
Sent: Thursday, April 18, 2019 11:05 AM
To: 'Open Object Rexx Developer Mailing List'
Cc: Mark L. Gaubatz
Subject: Re: [Oorexx-devel] An alternative algorithm for x2c()
Rony:
Too many comparisons are being done from a performance perspective; a minimal
comparison for validation and no comparison for translation is the fastest.
Actual translation should be done with a pair of 256-byte arrays for speed AND
portability across character sets. Speed varies according to caching levels on
each chipset as compared to ANSI specific translation that can be accomplished
with just register operations. I will note that in some of my speed tests on a
commercial product using newer Intel chipsets, caching brings only the cache
lines of the trio of 256-byte tables used for translation into faster operation
than the register operations. In addition, both upper- and lower-case A-F are
handled with no performance impact.
static const char trinvalid[256] = {… invalid character table … }; //
0x00 for valid characters, non-zero for invalid characters
static const char trhigh [256] = {… high order nibble translations … };
static const char trlow[256] = {… low order nibble translations … };
{
charc1 = hexdata[i];
charc2 = hexdata[i+1];
if ((trinvalid[c1] | trinvalid[c2])) // Yes, the | symbol is correct to
drop to a single comparison operation
{
data[0] = 0x00;
return false;
}
data[dIdx++] = trhigh[c1] | trlow[c2];
i += 2;
}
Mark
From: Rony G. Flatscher mailto:rony.flatsc...@wu.ac.at> >
Sent: Thursday, April 18, 2019 9:04 AM
To: Open Object Rexx Developer Mailing List mailto:oorexx-devel@lists.sourceforge.net> >
Subject: [Oorexx-devel] An alternative algorithm for x2c()
While experimenting a little bit with C code to decode hex strings I came up
with the following code:
boolean hex2char(CSTRING hexData, size_t len, char *data)
{
if (len % 2 == 1) // not an even number of hex characters
{
data[0]='\0';
return false;
}
size_t dIdx=0;
for (size_t i=0; iString(data, len/2);
free(data);
return rso;
}
Comparing the duration of x2c() with the above cppX2C() 1,000 times on a 512KB
string ( xrange("00"x,"FF"x)~copies(1000)~c2x ) the implementation of
hex2char() seems to be about 3,8 faster than x2c(). (This was tested on
Windows, 32-bit ooRexx.) Left the RexxRoutine1 cppX2C() in the above pasted
code, such that you could double-check it by merely copying and pasting the
above code and test it for yourself.
---rony
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] An alternative algorithm for x2c()
Rony:
Too many comparisons are being done from a performance perspective; a minimal
comparison for validation and no comparison for translation is the fastest.
Actual translation should be done with a pair of 256-byte arrays for speed AND
portability across character sets. Speed varies according to caching levels on
each chipset as compared to ANSI specific translation that can be accomplished
with just register operations. I will note that in some of my speed tests on a
commercial product using newer Intel chipsets, caching brings only the cache
lines of the trio of 256-byte tables used for translation into faster operation
than the register operations. In addition, both upper- and lower-case A-F are
handled with no performance impact.
static const char trinvalid[256] = {… invalid character table … }; //
0x00 for valid characters, non-zero for invalid characters
static const char trhigh [256] = {… high order nibble translations … };
static const char trlow[256] = {… low order nibble translations … };
{
charc1 = hexdata[i];
charc2 = hexdata[i+1];
if ((trinvalid[c1] | trinvalid[c2])) // Yes, the | symbol is correct to
drop to a single comparison operation
{
data[0] = 0x00;
return false;
}
data[dIdx++] = trhigh[c1] | trlow[c2];
i += 2;
}
Mark
From: Rony G. Flatscher
Sent: Thursday, April 18, 2019 9:04 AM
To: Open Object Rexx Developer Mailing List
Subject: [Oorexx-devel] An alternative algorithm for x2c()
While experimenting a little bit with C code to decode hex strings I came up
with the following code:
boolean hex2char(CSTRING hexData, size_t len, char *data)
{
if (len % 2 == 1) // not an even number of hex characters
{
data[0]='\0';
return false;
}
size_t dIdx=0;
for (size_t i=0; iString(data, len/2);
free(data);
return rso;
}
Comparing the duration of x2c() with the above cppX2C() 1,000 times on a 512KB
string ( xrange("00"x,"FF"x)~copies(1000)~c2x ) the implementation of
hex2char() seems to be about 3,8 faster than x2c(). (This was tested on
Windows, 32-bit ooRexx.) Left the RexxRoutine1 cppX2C() in the above pasted
code, such that you could double-check it by merely copying and pasting the
above code and test it for yourself.
---rony
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
