|
The generated code tends to be much simpler.
|
|
|
|
|
Yeah. Especially given the CodeDOM itself is so sparse.
My C# subset is about as simple as the codedom. a lot of non essential C# constructs like switch are gone.
In fact, there are only 3 things not in the codedom that i simulate for you in Slang - a while loop, the ! operator, and the != operator.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Yes, if you look at the IL for i++ vs ++i it's largely a re-ordering of when the pop happens.
|
|
|
|
|
I have not looked at IL much but I know it is a simple operation in assembler.
|
|
|
|
|
I don't think you ever NEED them!
All can ultimately be solved using regular + 1 and - 1 
|
|
|
|
|
Your fingers must hate you.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
It seems you're writing a lot more code than I do, and my code is being used... 
|
|
|
|
|
But does your code make you happy? Henggh?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Life is a dark, meaningless void.
We're thrust upon this coincidental floating space rock to live a meaningless life before we inevitably return to dust.
The question you should be asking me is if anything makes me happy at this point.
The answer is a resounding yes: bothering you about your single line if statements 
|
|
|
|
|
I'm glad to have brought some small measure of joy to your bleak, dreary existence.
Have you considered writing poetry? How about other forms of self harm? 
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: How about other forms of self harm?
I'm reading your Lounge messages, am I not?
|
|
|
|
|
That's fair.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
|
Voted up your 5 star article for that. It needs to be explained. Nice drill down.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Interesting.
While the article is correct for C it's not entirely correct for C#. C# actually defines the order of execution to be Left-associative or Right-associative depending on the operator. C# operators - C# reference | Microsoft Docs[^]
|
|
|
|
|
It is a very clear compiler optimization...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
Microsoft's C# compiler as a rule, does barely anything to optimize, punting it all to the jit compiler, which does peephole optimizations. It *may* optimize those out, and it may not. NGen'd assemblies might, but that's a different story.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I'm literally looking at the IL right now and there are no extra variables when using i++. What you see in the source isn't what is compiled to IL, and what is in IL isn't what is compiled to machine code, and what is compiled to machine code isn't what the CPU executes. You have to learn to stop worrying about how inefficient you think code looks and trust that everything downstream will work it out.
|
|
|
|
|
what's moved is where the pop is like you said. Most of the time, when small locals can be removed with stack operations they are. Has little to do with post, and pre, and everything to do with what's on the stack at that point. The internal extra storage is had by the stack rather than explicit var, so what? it's still storing it. It's just semantic at this point, because of where it's storing it. If the intermediary value isn't needed it doesn't need to be stored at all, and the fact that it is means *other* locals potentially cannot be moved to the stack.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
"x = ++i" loads i onto the stack, pushes 1 onto the stack, adds them, duplicates the return (so two copies of i+1 are on the stack), pops one into i and one into x.
"x = i++" loads i onto the stack, duplicates it (so there are two copies of i on the stack), pushes 1 onto the stack, adds them (now there is i and i+1 on the stack), pops one into i and one into x.
Both operations involve three stack values and six operations so are no more or less efficient than each other.
|
|
|
|
|
as long as there aren't any other variables being relocated to the stack at the time of your operation it holds. But if there is, then it doesn't, because the top of the stack is now a competed for resource between that variable and your post increment operator which was part of the point of my other reply.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: as long as there aren't any other variables being relocated to the stack at the time of your operation it holds
There aren't, and regardless the pre and post versions of the operator have the same access so neither is more or less efficient than each other. Besides, stack access is of no real concern when it comes to performance. The memory is pre-allocated and it simply involves changing a stack pointer.
|
|
|
|
|
all .NET IL ops that operate on the stack must operate on the TOP of the stack, so yes, it's a contested resource. In the case where there are two competing resources for doing ops, you must store in a local variable in IL, and operate on that.
Unlike x86 code you can't directly manipulate the stack pointer in IL, IIRC
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: all .NET IL ops that operate on the stack must operate on the TOP of the stack
Yes, that's how stacks work. In other news grass is green and water is wet.
honey the codewitch wrote: it's a contested resource.
That's a strawman argument, I didn't say it wasn't. You are also attempting to shift the goalposts away from the comparative performance of i++ vs ++i (your original argument) and onto if stack operations are performant or not. In terms of underlying code there is no difference in efficiency of i++ and ++i which is what your initial claim was.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
