2 added 111 characters in body
source | link

Yes, of course, in the right places. Would you rely on well tuned libraries such as the C++ standard libraries if they were written poorly and 10 times slower than they are today? Would everybody you've worked with have the same response to the previous question?

"C like" and "clever" aren't generally compliments in C++. Generic containers aren't inherently slow. In C++, abstraction layers can be written such that they cost next to nothing at runtime (if that is a concern).

Your energy (assuming it is finite) should not be evenly divided among lines. instead, look at the areas which get the most reuse/use and which more commonly serve as the foundation of other implementations if speed, size, and/or resource utilization are considerations. Staying close to the metal is easy when you are reusing and writing good implementations.

As libraries, kernels, hardware, compilers, etc. vary and advance, you will realize that you can't predict the optimal solution for every platform/system. You can't always win, nor should one attempt to always win given those great variations (consider somebody always twiddling implementations which use std::string for multiple SSO sizes). However, inefficient general purpose abstractions can quickly add up and cost several times more than well executed and efficient implementations.

The bottom line is "Yes, lazily written programs can easily be many times slower and resource hungry than well written programs".

Whether your drawing code (as an example) needs to be (or should be) ten times faster than it is today is another question. If the program were a small one trick pony, then it may not need any additional optimization. As complexity grows, these inefficiencies and poor resource utilization quickly become very significant problems. If you know the users will take your program to the ceiling of the hardware's capabilities often and time or performance are critical, you should take some time to consider multiple approaches to an implementation, and to write programs which are efficient early on.

Imagine how much better your computing experience would be if all programs you use today were 10 times faster, used far less memory, used good parallel forms, etc. -- the complexity of software grows almost as fast as hardware advances, but a lot of that 'growth' is also bloat and implementations which have not been well optimized. There's a lot of room for improvement.

Yes, of course, in the right places. Would you rely on well tuned libraries such as the C++ standard libraries if they were written poorly and 10 times slower than they are today? Would everybody you've worked with have the same response to the previous question?

"C like" and "clever" aren't generally compliments in C++. Generic containers aren't inherently slow. In C++, abstraction layers can be written such that they cost next to nothing at runtime (if that is a concern).

Your energy (assuming it is finite) should not be evenly divided among lines. instead, look at the areas which get the most reuse/use and which more commonly serve as the foundation of other implementations if speed, size, and/or resource utilization are considerations. Staying close to the metal is easy when you are reusing and writing good implementations.

As kernels, hardware, compilers, etc. vary and advance, you will realize that you can't predict the optimal solution for every platform/system. You can't always win, nor should one attempt to always win given those great variations. However, inefficient general purpose abstractions can quickly add up and cost several times more than well executed and efficient implementations.

The bottom line is "Yes, lazily written programs can easily be many times slower and resource hungry than well written programs".

Whether your drawing code (as an example) needs to be (or should be) ten times faster than it is today is another question. If the program were a small one trick pony, then it may not need any additional optimization. As complexity grows, these inefficiencies and poor resource utilization quickly become very significant problems. If you know the users will take your program to the ceiling of the hardware's capabilities often and time or performance are critical, you should take some time to consider multiple approaches to an implementation, and to write programs which are efficient early on.

Imagine how much better your computing experience would be if all programs you use today were 10 times faster, used far less memory, used good parallel forms, etc. -- the complexity of software grows almost as fast as hardware advances, but a lot of that 'growth' is also bloat and implementations which have not been well optimized. There's a lot of room for improvement.

Yes, of course, in the right places. Would you rely on well tuned libraries such as the C++ standard libraries if they were written poorly and 10 times slower than they are today? Would everybody you've worked with have the same response to the previous question?

"C like" and "clever" aren't generally compliments in C++. Generic containers aren't inherently slow. In C++, abstraction layers can be written such that they cost next to nothing at runtime (if that is a concern).

Your energy (assuming it is finite) should not be evenly divided among lines. instead, look at the areas which get the most reuse/use and which more commonly serve as the foundation of other implementations if speed, size, and/or resource utilization are considerations. Staying close to the metal is easy when you are reusing and writing good implementations.

As libraries, kernels, hardware, compilers, etc. vary and advance, you will realize that you can't predict the optimal solution for every platform/system. You can't always win, nor should one attempt to always win given those great variations (consider somebody always twiddling implementations which use std::string for multiple SSO sizes). However, inefficient general purpose abstractions can quickly add up and cost several times more than well executed and efficient implementations.

The bottom line is "Yes, lazily written programs can easily be many times slower and resource hungry than well written programs".

Whether your drawing code (as an example) needs to be (or should be) ten times faster than it is today is another question. If the program were a small one trick pony, then it may not need any additional optimization. As complexity grows, these inefficiencies and poor resource utilization quickly become very significant problems. If you know the users will take your program to the ceiling of the hardware's capabilities often and time or performance are critical, you should take some time to consider multiple approaches to an implementation, and to write programs which are efficient early on.

Imagine how much better your computing experience would be if all programs you use today were 10 times faster, used far less memory, used good parallel forms, etc. -- the complexity of software grows almost as fast as hardware advances, but a lot of that 'growth' is also bloat and implementations which have not been well optimized. There's a lot of room for improvement.

1
source | link

Yes, of course, in the right places. Would you rely on well tuned libraries such as the C++ standard libraries if they were written poorly and 10 times slower than they are today? Would everybody you've worked with have the same response to the previous question?

"C like" and "clever" aren't generally compliments in C++. Generic containers aren't inherently slow. In C++, abstraction layers can be written such that they cost next to nothing at runtime (if that is a concern).

Your energy (assuming it is finite) should not be evenly divided among lines. instead, look at the areas which get the most reuse/use and which more commonly serve as the foundation of other implementations if speed, size, and/or resource utilization are considerations. Staying close to the metal is easy when you are reusing and writing good implementations.

As kernels, hardware, compilers, etc. vary and advance, you will realize that you can't predict the optimal solution for every platform/system. You can't always win, nor should one attempt to always win given those great variations. However, inefficient general purpose abstractions can quickly add up and cost several times more than well executed and efficient implementations.

The bottom line is "Yes, lazily written programs can easily be many times slower and resource hungry than well written programs".

Whether your drawing code (as an example) needs to be (or should be) ten times faster than it is today is another question. If the program were a small one trick pony, then it may not need any additional optimization. As complexity grows, these inefficiencies and poor resource utilization quickly become very significant problems. If you know the users will take your program to the ceiling of the hardware's capabilities often and time or performance are critical, you should take some time to consider multiple approaches to an implementation, and to write programs which are efficient early on.

Imagine how much better your computing experience would be if all programs you use today were 10 times faster, used far less memory, used good parallel forms, etc. -- the complexity of software grows almost as fast as hardware advances, but a lot of that 'growth' is also bloat and implementations which have not been well optimized. There's a lot of room for improvement.