On 2/23/2010 11:48 AM, Krzysztof Kosiński wrote:
2010/2/22 Jon Cruz <jon@...18...>:
That proposed "fix" on the wiki really appears to be a work-around.
I do not agree with your definition of "fix" and "workaround". For me: Fix: something that removes the issue. Workaround: something that doesn't fix the issue but allows the program to function correctly.
Given those definitions, adding ifdefs to use some different hash implementation is a workaround, while the user replacing his broken header with a working one is a fix.
I think the exact opposite could be argued using your definitions too. Your proposed fix only works around the issue for a single user on a single machine but the problem remains for the next user. Jon's work around fixes the issue for everyone without requiring any more work on their part. This seems rather consistent with the intent of autoconf and other such tools: detect the capabilities of the platform and build properly. That's just one hugely well established work around.
More important is that we should only use an optimized data structure when required.
What is the difference between a normal data structure and "optimized" data structure? In my book, the standard hash set and hash map are normal data structures. Are you suggesting we should use structures that do not correctly represent the semantics of data (e.g. storing set elements in a vector) because it is somehow simpler, or that using the correct structure is premature optimization?
More important is that we should only use an optimized data structure when required. This includes measuring performance before and after the switch.
I replied to this before. I don't need any justification for using the theoretically optimal structure, but you do need benchmark data to demonstrate that some other theoretically suboptimal structure is better in practice.
Perhaps Jon is arguing that it is good to justify any _change_ with a benchmark. That seems reasonable to me. Use a benchmark to confirm that the theoretical optimality matches up well against your real world workload. Show that you have correctly understood the issue and that the expected gains have materialized.
Aaron Spike