HappySkeptic Wrote:You are still initializing the data in the constructor of TreeNode, every time. This is wasteful

I think both GCC and CLANG optimize that away. Namely, AECforWebAssembly v1.5.6 (the latest version) parses the Analog Clock example around 10 times faster than AECforWebAssembly v1.5 (before the recent changes).

The initialization may be fast with some compilers, but it cannot be optimized away.

(August 23, 2021 at 4:32 pm)HappySkeptic Wrote: The initialization may be fast with some compilers, but it cannot be optimized away.

Why?

(August 25, 2021 at 3:32 pm)FlatAssembler Wrote:

(August 23, 2021 at 4:32 pm)HappySkeptic Wrote: The initialization may be fast with some compilers, but it cannot be optimized away.

Why?

You are telling the code to do the initialization work when constructing each new instance of the TreeNode class.  The compiler MUST force the program to do that work, because it cannot assume the data has not changed since the last time the work was done.

(August 26, 2021 at 11:59 am)HappySkeptic Wrote:

(August 25, 2021 at 3:32 pm)FlatAssembler Wrote: Why?

You are telling the code to do the initialization work when constructing each new instance of the TreeNode class.  The compiler MUST force the program to do that work, because it cannot assume the data has not changed since the last time the work was done.

OK, I have changed that, but it seems to me my compiler is not any faster now than it was before that:
https://github.com/FlatAssembler/AECforW...e.cpp#L195

Okay, but at least you fixed that. It is too bad it didn't speed things up.

Just note - that this is an unsafe construct in a multi-threaded program (but yours isn't, so it is fine). With multi-threading, you have to use some sort of thread lock, not just a single variable.

(August 26, 2021 at 4:57 pm)HappySkeptic Wrote: Okay, but at least you fixed that.  It is too bad it didn't speed things up.

Just note - that this is an unsafe construct in a multi-threaded program (but yours isn't, so it is fine).  With multi-threading, you have to use some sort of thread lock, not just a single variable.

Like those locks from the C++ standard library? https://en.cppreference.com/w/cpp/thread/lock

(August 26, 2021 at 5:35 pm)FlatAssembler Wrote:

(August 26, 2021 at 4:57 pm)HappySkeptic Wrote: Okay, but at least you fixed that.  It is too bad it didn't speed things up.

Just note - that this is an unsafe construct in a multi-threaded program (but yours isn't, so it is fine).  With multi-threading, you have to use some sort of thread lock, not just a single variable.

Like those locks from the C++ standard library? https://en.cppreference.com/w/cpp/thread/lock

Yes.  However, getting a lock is also expensive, so in a thread-safe program you would find a way to do the static initialization at program startup, rather than test for initialization in the TreeNode constructor each time.

(August 26, 2021 at 5:44 pm)HappySkeptic Wrote:

(August 26, 2021 at 5:35 pm)FlatAssembler Wrote: Like those locks from the C++ standard library? https://en.cppreference.com/w/cpp/thread/lock

Yes.  However, getting a lock is also expensive, so in a thread-safe program you would find a way to do the static initialization at program startup, rather than test for initialization in the TreeNode constructor each time.

By the way, what do you think about the way I implemented named function arguments yesterday? https://github.com/FlatAssembler/AECforW....cpp#L1207
I don't know what to say, it seems to me I have once again made a compiler such that it is easier to start from scratch than to add another compilation target, just like it was easier to make a new compiler than to extend my AEC-to-x86 compiler to target WebAssembly. It would be very hard to extend my compiler to target, for example, LLVM bytecode instead of WebAssembly. Had I targetted LLVM bytecode, my programming language would already be able to run not only on the web, but also natively on ARM, and AVR, and PowerPC and SPARC. I hoped WebAssembly will turn into an easier-to-use LLVM, that there will soon be many WebAssembly-to-specific-CPU compilers, but it seems to me now that is not happening.

What do you guys here think about using `?:` in lvalues, that is, on the left-hand-side of the assignment operator? I have added support for that to my programming language: https://flatassembler.github.io/AEC_spec...l_operator