Lua 5.4.2 New assorted suggestions (Part II)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Ranier Vilela-2
Em sáb., 21 de nov. de 2020 às 14:38, Luiz Henrique de Figueiredo <[hidden email]> escreveu:
> /* avoid strlen call or inline */
> lua_pushlstring(L, "cannot close standard file", sizeof("cannot close standard file") - 1);

I suggest you use lua_pushliteral for string literals; it's good documentation.

lua_pushliteral is currently defined as lua_pushstring but in Lua 5.2
and previous versions it was defined as
#define lua_pushliteral(L, s)  lua_pushlstring(L, "" s,
(sizeof(s)/sizeof(char))-1)
See https://www.lua.org/source/5.2/lua.h.html#lua_pushliteral

You may want to redefine lua_pushliteral back to this if you are
worried about strlen on literals.
 It would be better for everyone in the Lua 5.4 git?
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Andre Leiradella-2
In reply to this post by Ranier Vilela-2

 For literal strings, lua_pushstring is both simpler to use and faster. 
lua_pushstring(L, "cannot close standard file");
Can be simpler, but it is not faster than:

/* avoid strlen call or inline */
lua_pushlstring(L, "cannot close standard file", sizeof("cannot close standard file") - 1);
Compilers nowadays won't call strlen for string literals: https://godbolt.org/z/s996MT

Don't assume, test, measure, look at the compiler's output.

Andre Leiradella

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Kyle Evans
In reply to this post by Ranier Vilela-2
On Sat, Nov 21, 2020 at 11:44 AM Ranier Vilela <[hidden email]> wrote:

>
> Em sáb., 21 de nov. de 2020 às 14:38, Luiz Henrique de Figueiredo <[hidden email]> escreveu:
>>
>> > /* avoid strlen call or inline */
>> > lua_pushlstring(L, "cannot close standard file", sizeof("cannot close standard file") - 1);
>>
>> I suggest you use lua_pushliteral for string literals; it's good documentation.
>>
>> lua_pushliteral is currently defined as lua_pushstring but in Lua 5.2
>> and previous versions it was defined as
>> #define lua_pushliteral(L, s)  lua_pushlstring(L, "" s,
>> (sizeof(s)/sizeof(char))-1)
>> See https://www.lua.org/source/5.2/lua.h.html#lua_pushliteral
>>
>> You may want to redefine lua_pushliteral back to this if you are
>> worried about strlen on literals.
>
>  It would be better for everyone in the Lua 5.4 git?

Please stop, unless you're going to actually benchmark or analyze this
stuff correctly. One brief look at the implementation of luaS_new vs.
luaS_newlstr and I cannot fathom why you would bother trying to
introduce performance regressions like this. I haven't looked at it
all that much, but I will eat my hat if you can prove that the
literals you're trying to convert to lua_pushlstring aren't in the
cache for over 95% of these invocations in the real world.
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Ranier Vilela-2
Em sáb., 21 de nov. de 2020 às 16:05, Kyle Evans <[hidden email]> escreveu:
On Sat, Nov 21, 2020 at 11:44 AM Ranier Vilela <[hidden email]> wrote:
>
> Em sáb., 21 de nov. de 2020 às 14:38, Luiz Henrique de Figueiredo <[hidden email]> escreveu:
>>
>> > /* avoid strlen call or inline */
>> > lua_pushlstring(L, "cannot close standard file", sizeof("cannot close standard file") - 1);
>>
>> I suggest you use lua_pushliteral for string literals; it's good documentation.
>>
>> lua_pushliteral is currently defined as lua_pushstring but in Lua 5.2
>> and previous versions it was defined as
>> #define lua_pushliteral(L, s)  lua_pushlstring(L, "" s,
>> (sizeof(s)/sizeof(char))-1)
>> See https://www.lua.org/source/5.2/lua.h.html#lua_pushliteral
>>
>> You may want to redefine lua_pushliteral back to this if you are
>> worried about strlen on literals.
>
>  It would be better for everyone in the Lua 5.4 git?

Please stop, unless you're going to actually benchmark or analyze this
stuff correctly. One brief look at the implementation of luaS_new vs.
luaS_newlstr and I cannot fathom why you would bother trying to
introduce performance regressions like this. I haven't looked at it
all that much, but I will eat my hat if you can prove that the
literals you're trying to convert to lua_pushlstring aren't in the
cache for over 95% of these invocations in the real world.
I think you are right here, but for the wrong reason.
In luaT_init, the cache will most likely be empty.
But when changing LuaS_new for luaS_newlstr, the cache initialization is lost, so it really isn't worth it.
Perhaps, if luaS_newlen (lua_State * L, const char * str, size_t len), was created, let it go.
So I take that example back.
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Kyle Evans
On Sat, Nov 21, 2020 at 2:44 PM Ranier Vilela <[hidden email]> wrote:

>
> Em sáb., 21 de nov. de 2020 às 16:05, Kyle Evans <[hidden email]> escreveu:
>>
>> On Sat, Nov 21, 2020 at 11:44 AM Ranier Vilela <[hidden email]> wrote:
>> >
>> > Em sáb., 21 de nov. de 2020 às 14:38, Luiz Henrique de Figueiredo <[hidden email]> escreveu:
>> >>
>> >> > /* avoid strlen call or inline */
>> >> > lua_pushlstring(L, "cannot close standard file", sizeof("cannot close standard file") - 1);
>> >>
>> >> I suggest you use lua_pushliteral for string literals; it's good documentation.
>> >>
>> >> lua_pushliteral is currently defined as lua_pushstring but in Lua 5.2
>> >> and previous versions it was defined as
>> >> #define lua_pushliteral(L, s)  lua_pushlstring(L, "" s,
>> >> (sizeof(s)/sizeof(char))-1)
>> >> See https://www.lua.org/source/5.2/lua.h.html#lua_pushliteral
>> >>
>> >> You may want to redefine lua_pushliteral back to this if you are
>> >> worried about strlen on literals.
>> >
>> >  It would be better for everyone in the Lua 5.4 git?
>>
>> Please stop, unless you're going to actually benchmark or analyze this
>> stuff correctly. One brief look at the implementation of luaS_new vs.
>> luaS_newlstr and I cannot fathom why you would bother trying to
>> introduce performance regressions like this. I haven't looked at it
>> all that much, but I will eat my hat if you can prove that the
>> literals you're trying to convert to lua_pushlstring aren't in the
>> cache for over 95% of these invocations in the real world.
>
> I think you are right here, but for the wrong reason.
> In luaT_init, the cache will most likely be empty.
> But when changing LuaS_new for luaS_newlstr, the cache initialization is lost, so it really isn't worth it.
> Perhaps, if luaS_newlen (lua_State * L, const char * str, size_t len), was created, let it go.
> So I take that example back.

Ok, that's a good start. Can you explain why, for the rest of these,
you're advocating for luaL_addlstring vs. just providing an internal
luaL_addstring macro in some header that does exactly what
luaL_addstring does?

Note that any optimizing compiler worth its salt should be able
to identify that it can eliminate the strlen() call at the call sites
where it's a literal, providing a less-redundant interface that's
"optimal" (not that I think it's necessarily
worth it).

Thanks,

Kyle Evans
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Ranier Vilela-2
Em dom., 22 de nov. de 2020 às 18:13, Kyle Evans <[hidden email]> escreveu:
On Sat, Nov 21, 2020 at 2:44 PM Ranier Vilela <[hidden email]> wrote:
>
> Em sáb., 21 de nov. de 2020 às 16:05, Kyle Evans <[hidden email]> escreveu:
>>
>> On Sat, Nov 21, 2020 at 11:44 AM Ranier Vilela <[hidden email]> wrote:
>> >
>> > Em sáb., 21 de nov. de 2020 às 14:38, Luiz Henrique de Figueiredo <[hidden email]> escreveu:
>> >>
>> >> > /* avoid strlen call or inline */
>> >> > lua_pushlstring(L, "cannot close standard file", sizeof("cannot close standard file") - 1);
>> >>
>> >> I suggest you use lua_pushliteral for string literals; it's good documentation.
>> >>
>> >> lua_pushliteral is currently defined as lua_pushstring but in Lua 5.2
>> >> and previous versions it was defined as
>> >> #define lua_pushliteral(L, s)  lua_pushlstring(L, "" s,
>> >> (sizeof(s)/sizeof(char))-1)
>> >> See https://www.lua.org/source/5.2/lua.h.html#lua_pushliteral
>> >>
>> >> You may want to redefine lua_pushliteral back to this if you are
>> >> worried about strlen on literals.
>> >
>> >  It would be better for everyone in the Lua 5.4 git?
>>
>> Please stop, unless you're going to actually benchmark or analyze this
>> stuff correctly. One brief look at the implementation of luaS_new vs.
>> luaS_newlstr and I cannot fathom why you would bother trying to
>> introduce performance regressions like this. I haven't looked at it
>> all that much, but I will eat my hat if you can prove that the
>> literals you're trying to convert to lua_pushlstring aren't in the
>> cache for over 95% of these invocations in the real world.
>
> I think you are right here, but for the wrong reason.
> In luaT_init, the cache will most likely be empty.
> But when changing LuaS_new for luaS_newlstr, the cache initialization is lost, so it really isn't worth it.
> Perhaps, if luaS_newlen (lua_State * L, const char * str, size_t len), was created, let it go.
> So I take that example back.

Ok, that's a good start. Can you explain why, for the rest of these,
you're advocating for luaL_addlstring vs. just providing an internal
luaL_addstring macro in some header that does exactly what
luaL_addstring does?
Yeah, it would be a better code style.
The interface present in:
https://www.lua.org/source/5.2/lua.h.html#lua_pushliteral
It was ideal to add constant strings, I think.
The code would be more readable.


Note that any optimizing compiler worth its salt should be able
to identify that it can eliminate the strlen() call at the call sites
where it's a literal, providing a less-redundant interface that's
"optimal" (not that I think it's necessarily
worth it).
I come from the old school, from the days of the MSDOS.
From my first C course, one of the lessons was: don't leave anything behind.
Indeed, compilers have evolved a lot.
But the one who knows the code and the data best is the programmer, not the compiler.
Then give permission to optimize and the compiler will do a better job.
It is the same principle of using const, many do not, because the code is less readable.

regards,
Ranier Vilela
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Luiz Henrique de Figueiredo
> The interface present in:
> https://www.lua.org/source/5.2/lua.h.html#lua_pushliteral
> It was ideal to add constant strings, I think.
> The code would be more readable.

Yes. Do use lua_pushliteral when dealing with literal strings.
It's good documentation and allows optimizations in the past and in the future.
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Kyle Evans
In reply to this post by Ranier Vilela-2
On Mon, Nov 23, 2020 at 5:38 AM Ranier Vilela <[hidden email]> wrote:

>
> Em dom., 22 de nov. de 2020 às 18:13, Kyle Evans <[hidden email]> escreveu:
>> Note that any optimizing compiler worth its salt should be able
>> to identify that it can eliminate the strlen() call at the call sites
>> where it's a literal, providing a less-redundant interface that's
>> "optimal" (not that I think it's necessarily
>> worth it).
>
> I come from the old school, from the days of the MSDOS.
> From my first C course, one of the lessons was: don't leave anything behind.
> Indeed, compilers have evolved a lot.
> But the one who knows the code and the data best is the programmer, not the compiler.
> Then give permission to optimize and the compiler will do a better job.
> It is the same principle of using const, many do not, because the code is less readable.
>

Sure, I'll bow out here, but your approach here could be improved with
an eye towards balancing aesthetics and performance. lua_pushliteral
is better, but the authors have chosen what they have and likely have
a good reason for it given that they've developed both sides of the
API. For instance, proposing an invasive change that sprinkles
sizeof() at each of these invocations is probably not going to be
received well, but a macro gated behind LUA_CORE that doesn't change
the aesthetics of the call sites while still eliminating a call very
well might. If the authors think it's silly and a better choice could
have been made at those callers that you've noted are affected by the
macro, then you've still accomplished something productive.

The other thing to remember is that while you may still have scars
from compilers of the past, trying to outrun compiler optimizations
isn't really all that worthwhile (at least nowadays) over writing
clear and concise code for most applications.

I say all of the above from the perspective of someone that maintains
other projects and regularly reviews submissions from other people.

Thanks,

Kyle Evans
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Ranier Vilela-2
Em seg., 23 de nov. de 2020 às 11:02, Kyle Evans <[hidden email]> escreveu:
On Mon, Nov 23, 2020 at 5:38 AM Ranier Vilela <[hidden email]> wrote:
>
> Em dom., 22 de nov. de 2020 às 18:13, Kyle Evans <[hidden email]> escreveu:
>> Note that any optimizing compiler worth its salt should be able
>> to identify that it can eliminate the strlen() call at the call sites
>> where it's a literal, providing a less-redundant interface that's
>> "optimal" (not that I think it's necessarily
>> worth it).
>
> I come from the old school, from the days of the MSDOS.
> From my first C course, one of the lessons was: don't leave anything behind.
> Indeed, compilers have evolved a lot.
> But the one who knows the code and the data best is the programmer, not the compiler.
> Then give permission to optimize and the compiler will do a better job.
> It is the same principle of using const, many do not, because the code is less readable.
>

Sure, I'll bow out here, but your approach here could be improved with
an eye towards balancing aesthetics and performance. lua_pushliteral
is better, but the authors have chosen what they have and likely have
a good reason for it given that they've developed both sides of the
API. For instance, proposing an invasive change that sprinkles
sizeof() at each of these invocations is probably not going to be
received well, but a macro gated behind LUA_CORE that doesn't change
the aesthetics of the call sites while still eliminating a call very
well might. If the authors think it's silly and a better choice could
have been made at those callers that you've noted are affected by the
macro, then you've still accomplished something productive.
Ok, thanks for the hit, I will remember that.

The other thing to remember is that while you may still have scars
from compilers of the past, trying to outrun compiler optimizations
isn't really all that worthwhile (at least nowadays) over writing
clear and concise code for most applications.
It's always a good rule.

I say all of the above from the perspective of someone that maintains
other projects and regularly reviews submissions from other people.
Please, always reject politely, people, they spend time too.
A simple, no thanks, is enough.

regards,
Ranier Vilela
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Ranier Vilela-2
In reply to this post by Kyle Evans
Em seg., 23 de nov. de 2020 às 11:02, Kyle Evans <[hidden email]> escreveu:
On Mon, Nov 23, 2020 at 5:38 AM Ranier Vilela <[hidden email]> wrote:
>
> Em dom., 22 de nov. de 2020 às 18:13, Kyle Evans <[hidden email]> escreveu:
>> Note that any optimizing compiler worth its salt should be able
>> to identify that it can eliminate the strlen() call at the call sites
>> where it's a literal, providing a less-redundant interface that's
>> "optimal" (not that I think it's necessarily
>> worth it).
>
> I come from the old school, from the days of the MSDOS.
> From my first C course, one of the lessons was: don't leave anything behind.
> Indeed, compilers have evolved a lot.
> But the one who knows the code and the data best is the programmer, not the compiler.
> Then give permission to optimize and the compiler will do a better job.
> It is the same principle of using const, many do not, because the code is less readable.
>

Sure, I'll bow out here.
I would like, at least, once again, your opinion, in this example below, if you don't mind.
When the programmer knows the data, better than the compiler.

LUA API luaS_newshortstr
1. Avoid "if test" when the size of string is < LUAI_MAXSHORTLEN.


lstring.c
@@ -185,15 +185,15 @@ static void growstrtab (lua_State *L, stringtable *tb) {
 /*
 ** Checks whether short string exists and reuses it or creates a new one.
 */
-static TString *internshrstr (lua_State *L, const char *str, size_t l) {
+TString *luaS_newshortstr (lua_State *L, const char * const str, size_t l) {

@@ -218,9 +217,9 @@ static TString *internshrstr (lua_State *L, const char *str, size_t l) {
 /*
 ** new string (with explicit length)
 */
-    return internshrstr(L, str, l);
+    return luaS_newshortstr(L, str, l);

lapi.c
@@ -1256,7 +1256,7 @@ LUA_API void lua_concat (lua_State *L, int n) {
   if (n > 0)
     luaV_concat(L, n);
   else {  /* nothing to concatenate */
-    setsvalue2s(L, L->top, luaS_newlstr(L, "", 0));  /* push empty string */
+    setsvalue2s(L, L->top, luaS_newshortstr(L, "", 0));  /* push empty string */


+++ b/lobject.c
@@ -372,9 +372,9 @@ static int tostringbuff (TValue *obj, char *buff) {
 ** Convert a number object to a Lua string, replacing the value at 'obj'
 */
 void luaO_tostring (lua_State *L, TValue *obj) {
-  char buff[MAXNUMBER2STR];
+  char buff[LUAI_MAXSHORTLEN];
   int len = tostringbuff(obj, buff);
-  setsvalue(L, obj, luaS_newlstr(L, buff, len));
+  setsvalue(L, obj, luaS_newshortstr(L, buff, len));

+++ b/lvm.c
 /* copy strings in stack from top - n up to top - 1 to buffer */
 static void copy2buff (StkId top, int n, char *buff) {
@@ -661,7 +661,7 @@ void luaV_concat (lua_State *L, int total) {
       if (tl <= LUAI_MAXSHORTLEN) {  /* is result a short string? */
         char buff[LUAI_MAXSHORTLEN];
         copy2buff(top, n, buff);  /* copy strings to buffer */
-        ts = luaS_newlstr(L, buff, tl);
+        ts = luaS_newshortstr(L, buff, tl);

diff --git a/lundump.c b/lundump.c
index 5aa55c44..b763d0fa 100644
--- a/lundump.c
+++ b/lundump.c
@@ -116,7 +116,7 @@ static TString *loadStringN (LoadState *S, Proto *p) {
   else if (--size <= LUAI_MAXSHORTLEN) {  /* short string? */
     char buff[LUAI_MAXSHORTLEN];
     loadVector(S, buff, size);  /* load string into buffer */
-    ts = luaS_newlstr(L, buff, size);  /* create string */
+    ts = luaS_newshortstr(L, buff, size);  /* create string */
   }
   else {  /* long string */
     ts = luaS_createlngstrobj(L, size);  /* create string */

What do you think?

regards,
Ranier Vilela
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Kyle Evans
On Mon, Nov 23, 2020 at 10:20 AM Ranier Vilela <[hidden email]> wrote:

>
> Em seg., 23 de nov. de 2020 às 11:02, Kyle Evans <[hidden email]> escreveu:
>>
>> On Mon, Nov 23, 2020 at 5:38 AM Ranier Vilela <[hidden email]> wrote:
>> >
>> > Em dom., 22 de nov. de 2020 às 18:13, Kyle Evans <[hidden email]> escreveu:
>> >> Note that any optimizing compiler worth its salt should be able
>> >> to identify that it can eliminate the strlen() call at the call sites
>> >> where it's a literal, providing a less-redundant interface that's
>> >> "optimal" (not that I think it's necessarily
>> >> worth it).
>> >
>> > I come from the old school, from the days of the MSDOS.
>> > From my first C course, one of the lessons was: don't leave anything behind.
>> > Indeed, compilers have evolved a lot.
>> > But the one who knows the code and the data best is the programmer, not the compiler.
>> > Then give permission to optimize and the compiler will do a better job.
>> > It is the same principle of using const, many do not, because the code is less readable.
>> >
>>
>> Sure, I'll bow out here.
>
> I would like, at least, once again, your opinion, in this example below, if you don't mind.
> When the programmer knows the data, better than the compiler.
>
> LUA API luaS_newshortstr
> 1. Avoid "if test" when the size of string is < LUAI_MAXSHORTLEN.
>

The patch below seems to be truncated in some sense, because it
doesn't seem to do what's just been described. Notably, the
description leads me to believe that it's supposed to eliminate some
branching, but that doesn't seem to have happened.

Btw, I think we should take this off-list if you'd like my input,
rather than adding more tangentially related e-mail during an ongoing
release cycle. Not to say that there's no educational value in this
discussion, but I suspect it would be greatly appreciated to converge
on some agreeable set of changes (or maybe even no changes, if it
works out that way) before revisiting the topic on-list.

>
> lstring.c
> @@ -185,15 +185,15 @@ static void growstrtab (lua_State *L, stringtable *tb) {
>  /*
>  ** Checks whether short string exists and reuses it or creates a new one.
>  */
> -static TString *internshrstr (lua_State *L, const char *str, size_t l) {
> +TString *luaS_newshortstr (lua_State *L, const char * const str, size_t l) {
>
> @@ -218,9 +217,9 @@ static TString *internshrstr (lua_State *L, const char *str, size_t l) {
>  /*
>  ** new string (with explicit length)
>  */
> -    return internshrstr(L, str, l);
> +    return luaS_newshortstr(L, str, l);
>
> lapi.c
> @@ -1256,7 +1256,7 @@ LUA_API void lua_concat (lua_State *L, int n) {
>    if (n > 0)
>      luaV_concat(L, n);
>    else {  /* nothing to concatenate */
> -    setsvalue2s(L, L->top, luaS_newlstr(L, "", 0));  /* push empty string */
> +    setsvalue2s(L, L->top, luaS_newshortstr(L, "", 0));  /* push empty string */
>
>
> +++ b/lobject.c
> @@ -372,9 +372,9 @@ static int tostringbuff (TValue *obj, char *buff) {
>  ** Convert a number object to a Lua string, replacing the value at 'obj'
>  */
>  void luaO_tostring (lua_State *L, TValue *obj) {
> -  char buff[MAXNUMBER2STR];
> +  char buff[LUAI_MAXSHORTLEN];
>    int len = tostringbuff(obj, buff);
> -  setsvalue(L, obj, luaS_newlstr(L, buff, len));
> +  setsvalue(L, obj, luaS_newshortstr(L, buff, len));
>
> +++ b/lvm.c
>  /* copy strings in stack from top - n up to top - 1 to buffer */
>  static void copy2buff (StkId top, int n, char *buff) {
> @@ -661,7 +661,7 @@ void luaV_concat (lua_State *L, int total) {
>        if (tl <= LUAI_MAXSHORTLEN) {  /* is result a short string? */
>          char buff[LUAI_MAXSHORTLEN];
>          copy2buff(top, n, buff);  /* copy strings to buffer */
> -        ts = luaS_newlstr(L, buff, tl);
> +        ts = luaS_newshortstr(L, buff, tl);
>
> diff --git a/lundump.c b/lundump.c
> index 5aa55c44..b763d0fa 100644
> --- a/lundump.c
> +++ b/lundump.c
> @@ -116,7 +116,7 @@ static TString *loadStringN (LoadState *S, Proto *p) {
>    else if (--size <= LUAI_MAXSHORTLEN) {  /* short string? */
>      char buff[LUAI_MAXSHORTLEN];
>      loadVector(S, buff, size);  /* load string into buffer */
> -    ts = luaS_newlstr(L, buff, size);  /* create string */
> +    ts = luaS_newshortstr(L, buff, size);  /* create string */
>    }
>    else {  /* long string */
>      ts = luaS_createlngstrobj(L, size);  /* create string */
>
> What do you think?
>
> regards,
> Ranier Vilela
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Ranier Vilela-2
Em seg., 23 de nov. de 2020 às 13:32, Kyle Evans <[hidden email]> escreveu:
On Mon, Nov 23, 2020 at 10:20 AM Ranier Vilela <[hidden email]> wrote:
>
> Em seg., 23 de nov. de 2020 às 11:02, Kyle Evans <[hidden email]> escreveu:
>>
>> On Mon, Nov 23, 2020 at 5:38 AM Ranier Vilela <[hidden email]> wrote:
>> >
>> > Em dom., 22 de nov. de 2020 às 18:13, Kyle Evans <[hidden email]> escreveu:
>> >> Note that any optimizing compiler worth its salt should be able
>> >> to identify that it can eliminate the strlen() call at the call sites
>> >> where it's a literal, providing a less-redundant interface that's
>> >> "optimal" (not that I think it's necessarily
>> >> worth it).
>> >
>> > I come from the old school, from the days of the MSDOS.
>> > From my first C course, one of the lessons was: don't leave anything behind.
>> > Indeed, compilers have evolved a lot.
>> > But the one who knows the code and the data best is the programmer, not the compiler.
>> > Then give permission to optimize and the compiler will do a better job.
>> > It is the same principle of using const, many do not, because the code is less readable.
>> >
>>
>> Sure, I'll bow out here.
>
> I would like, at least, once again, your opinion, in this example below, if you don't mind.
> When the programmer knows the data, better than the compiler.
>
> LUA API luaS_newshortstr
> 1. Avoid "if test" when the size of string is < LUAI_MAXSHORTLEN.
>

The patch below seems to be truncated in some sense, because it
doesn't seem to do what's just been described. Notably, the
description leads me to believe that it's supposed to eliminate some
branching, but that doesn't seem to have happened.

Btw, I think we should take this off-list if you'd like my input,
rather than adding more tangentially related e-mail during an ongoing
release cycle. Not to say that there's no educational value in this
discussion, but I suspect it would be greatly appreciated to converge
on some agreeable set of changes (or maybe even no changes, if it
works out that way) before revisiting the topic on-list.
Ok, I sent the patch to your email.

regards,
Ranier Vilela
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Will Crowder
In reply to this post by Kyle Evans
On Mon, 2020-11-23 at 08:01 -0600, Kyle Evans wrote:
The other thing to remember is that while you may still have scars
from compilers of the past, trying to outrun compiler optimizations
isn't really all that worthwhile (at least nowadays) over writing
clear and concise code for most applications.
Indeed.  Optimize the design and at the higher levels of the implementation.  One is quite unlikely to out-micro-optimize a modern compiler, and code clarity and conciseness pays off in so many ways.

Back when C really was just "the greatest macroassembler ever written," code-level micro-optimizations made sense.  But compiler technology has come a long way since then.

Will

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4.2 New assorted suggestions (Part II)

Gé Weijers
On Mon, Nov 23, 2020 at 8:53 AM Will Crowder <[hidden email]> wrote:
> Back when C really was just "the greatest macroassembler ever written," code-level micro-optimizations made sense.  But compiler technology has come a long way since then.

I remember when you could predict the code generated by the original
PDP-11 C compiler on the 7th edition Unix system. Adding "register"
variables and using post-increment or pre-decrement on pointers could
really speed up your code. That's no longer the case, the compiler
often has a better grasp on the behavior of modern CPUs than the
programmer. You can 'optimize' your code only to find that you added
dependencies between instructions that lead to more pipeline stalls or
that the "optimized" code grew the data structure beyond your cache
size, leading to lots of cache misses. An optimization for one
architecture can make things worse on another as well.


--

12