-
Notifications
You must be signed in to change notification settings - Fork 53
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
process xor/rol optimised and fully implemented (thanks @webbnh)
- Loading branch information
1 parent
14b9bd8
commit 6fccdb8
Showing
2 changed files
with
89 additions
and
15 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
6fccdb8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe all the show-stoppers have been resolved.
Were it up to me, I would decline the the changes to
process_xor_one()
andprocess_xor_many()
: most of them are unnecessary code churn, and the ones which are actually operable are (very slightly) slowing down the main cases in order to optimize degenerate cases (which, if the calling code actually cares, it can easily handle itself).And, again, I don't think adding the "warnings" to the header actually helps anything.
But, I think we're done, here.
6fccdb8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you meant the
key == 0
andkey == [0]
then no, the compiler cannot detect those situations if those values come from a variable, not a constant.6fccdb8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I meant was, if a developer has a dataset where the "key" will be zero (meaning that no actual processing is required) or where a "multi-byte key" might be only one byte long (meaning that his code should use
'xor_one
instead of'xor_many
), then it should be his application which pays the performance penalty, if he doesn't take the necessary steps to avoid it. (And, there actually is no loss in the zero-key case -- only a failure to "gain" -- relative to a non-zero key; and, I think an analogous statement applies to the one-byte key case.) I think this is a more appropriate approach than placing a(n albeit small) burden on all other developers' usages, given that they would have no way to avoid it.I think you are largely correct that the KS compiler cannot detect these situations (especially, it cannot do so without burdening the normal cases), but I think a developer can use KSY directives to detect the degenerate cases and take appropriate actions if the benefits are worth the complication to him.