Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualcronocr

Posted 24 May 2013 - 11:16 AM

How is this actually slowing your program?
 
How is this something that actually needs a programmer to optimize it?

 

You might manage to save a cycle or two if you hunt for things like this, but hunting for spare nanoseconds is not generally a good use of time.

 

Code optimization is generally about saving microseconds or bigger time units.

 

At the level I'm currently optimizing the system, everything is slowing it down. I already designed an optimized solution, and profiled the system to the "smallest" millisecond. Now I'm ready for the nanoseconds. Why doing this? Because it's cheap doing it with the automated inlining tool I have built.

 

 

You are right that boxing is somewhat slow, so DON'T DO IT.  If you end up needing to routinely convert integers and bools into objects, you are likely doing something wrong at the algorithm level.  

 

It's almost impossible not to generate boxing, not in a system with 9000+ lines of code. The way to actually get rid of it is inlining, so I'm going to do it.

 

 

Similarly, the 'is' operator is not exactly fast, and its presence is a generally symptom of a more significant fundamental design problem.  Casting an object to some type and then discarding the results is horrible anyway; if you cannot fix your algorithm's underlying problem that requires the cast, at least have the decency to perform the cast with 'as' and keep the successful results around.

 

Using the "is" operator is just a trick to convert the statement into a expression, the idea is finding a way for the compiler to remove it later, so it doesn't represent any cost.

 

 

Next up, chaining doesn't necessarily mean better performance -- each item is dependent on the previous results which is bad for the pipeline.  You can get pipeline bubbles or poor use of speculative execution and branch prediction if you make it too tight.  On modern hardware keeping it loose is usually better.  

 

We are not talking of the same thing here. I might have used a wrong term when referring to the AND operator, that "chains/adds/joins" expressions, so the execution sequence is respected.


#2cronocr

Posted 24 May 2013 - 10:52 AM

How is this actually slowing your program?
 
How is this something that actually needs a programmer to optimize it?

 

You might manage to save a cycle or two if you hunt for things like this, but hunting for spare nanoseconds is not generally a good use of time.

 

Code optimization is generally about saving microseconds or bigger time units.

 

At the level I'm currently optimizing the system, everything is slowing it down. I already designed an optimized solution, and profiled the system to the "smallest" millisecond. Now I'm ready for the nanoseconds. Why doing this? Because it's cheap doing it with the automated inlining tool I have built.

 

 

You are right that boxing is somewhat slow, so DON'T DO IT.  If you end up needing to routinely convert integers and bools into objects, you are likely doing something wrong at the algorithm level.  

 

It's almost impossible not to generate boxing, not in a system with 9000+ lines of code. The way to actually get rid of it is inlining, so I'm going to do it.

 

 

Similarly, the 'is' operator is not exactly fast, and its presence is a generally symptom of a more significant fundamental design problem.  Casting an object to some type and then discarding the results is horrible anyway; if you cannot fix your algorithm's underlying problem that requires the cast, at least have the decency to perform the cast with 'as' and keep the successful results around.

 

Using the "is" operator is just a trick to convert the statement into a expression, the idea is finding a way for the compiler to remove it later, so it doesn't represent any cost.

 

 

Next up, chaining doesn't necessarily mean better performance -- each item is dependent on the previous results which is bad for the pipeline.  You can get pipeline bubbles or poor use of speculative execution and branch prediction if you make it too tight.  On modern hardware keeping it loose is usually better.  

 

Where are not talking of the same thing here. I might have used a wrong term when referring to the AND operator, that "chains/adds/joins" expressions, so the execution sequence is respected.


#1cronocr

Posted 24 May 2013 - 10:51 AM

How is this actually slowing your program?
 
How is this something that actually needs a programmer to optimize it?

 

You might manage to save a cycle or two if you hunt for things like this, but hunting for spare nanoseconds is not generally a good use of time.

 

Code optimization is generally about saving microseconds or bigger time units.

 

At the level I'm currently optimizing the system, everything is slowing it down. I already designed a optimized solution, and profiled the system to smallest millisecond. Now I'm ready for the nanoseconds. Why doing this? Because it's cheap doing it with the automated inlining tool I have built.

 

You are right that boxing is somewhat slow, so DON'T DO IT.  If you end up needing to routinely convert integers and bools into objects, you are likely doing something wrong at the algorithm level.  

 

It's almost impossible not to generate boxing, not in a system with 9000+ lines of code. The way to actually get rid of it is inlining, so I'm going to do it.

 

Similarly, the 'is' operator is not exactly fast, and its presence is a generally symptom of a more significant fundamental design problem.  Casting an object to some type and then discarding the results is horrible anyway; if you cannot fix your algorithm's underlying problem that requires the cast, at least have the decency to perform the cast with 'as' and keep the successful results around.

 

Using the "is" operator is just a trick to convert the statement into a expression, the idea is finding a way for the compiler to remove it later, so it doesn't represent any cost.

 

Next up, chaining doesn't necessarily mean better performance -- each item is dependent on the previous results which is bad for the pipeline.  You can get pipeline bubbles or poor use of speculative execution and branch prediction if you make it too tight.  On modern hardware keeping it loose is usually better.  

 

Where are not talking of the same thing here. I might have used a wrong term when referring to the AND operator, that "chains/adds/joins" expressions, so the execution sequence is respected.


PARTNERS