| olcott <NoOne@NoWhere.com>: May 10 02:36PM -0500 On 5/10/2021 2:22 PM, Mike Terry wrote: > Now you're being childish - you know perfectly well that I have never > agreed that your "proof" is correct. So you are deliberately > misrepresenting my views (again). http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf This is from my current proof. void H_Hat(u32 P) { u32 Input_Halts = Halts(P, P); if (Input_Halts) HERE: goto HERE; } int main() { u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat); Output("Input_Would_Halt = ", Input_Would_Halt); } This is agreement that Halts() correctly decides H_Hat() as non-halting thus perfect agreement with the entire conclusion of my current proof. On 11/20/2020 9:30 PM, Mike Terry wrote: -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Juha Nieminen <nospam@thanks.invalid>: May 10 05:07AM > Yes and in many situations like with IEEE 754 types we may benefit > from quaternary comparison results. But if it brings any performance > benefits is unclear until shown by profiler. And I still maintain that only an astronomically minuscule fraction of projects out there, especially commercial projects, are going to go back to an existing project, profile it, find out the bottlenecks and fix them. The theory "only optimize after a profiler has shown that there's a bottleneck" is utterly naive and flawed. In practice, it's in essence completely equal to "never optimize". My point is that if you optimize *now* you won't have to optimize later. You'll get the benefits from the get-go, and the program will be more optimized. The "optimize later" phase is not going to happen 99.9999% of the time, especially when we are talking about commercial products. (There are many other things for which the same is true. Such as cleaning up and commenting the code. "I'll comment the code later" is in essence the equivalent of "I'll never comment this code". If you don't comment the code now, you are not going to comment it ever. Not in a commercial product, most probably not even in a hobby project.) |
| Richard Damon <Richard@Damon-Family.org>: May 10 07:29AM -0400 On 5/10/21 1:07 AM, Juha Nieminen wrote: > the equivalent of "I'll never comment this code". If you don't comment the > code now, you are not going to comment it ever. Not in a commercial product, > most probably not even in a hobby project.) The key to the addage about premature optimization is that if you spend time to work on adding 'tricks' to your code to make it faster, almost always at the expense of code clarity, then this will end up slowing down your develpment process because you WILL be tracing down bugs that you made due to trying to be tricky to make code faster that never needed to be faster. This does NOT mean not spending a bit of time to use the right algorithms that will have a reasonable speed/complexity ratio for your application, or use bad techniques on the way. You don't normally 'go back' to a released product to try and speed it up, but you get along in the design and as part of testing you find the system is running slower than you want, so as PART of the development you see a NEED for better speed, so you profile, find bottle-necks, and apply optimization there. There is also the fact that probably at least half of the optimization techniques that are used to micro-optimize can be done better by a good compiler, and often by trying to do it yourself you hurt the copilers ability to do a better job. Note, as I said, this does NOT mean you bad algorithms. You have a big table of data you need to find something in it. Thinking a minute to see if a linear seach to find it would be bad is NOT 'pre-mature optimization', it is good design. At minimum you encapsulate the decision of what technique will be used to look up the data lookup so when you figure out the exact pattern to your data access, you can chose what method to use. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment