|
RE: RE: Obfuscate my perl code
by little (Curate) on Oct 27, 2000 at 18:34 UTC
|
That leads me to one question:
Does anyone of You know a case where the obfuscated code runs faster than the original???
I mean would there be a practical and pragramatical reason to check for this also??
Have a nice day
All decision is left to your taste | [reply] |
|
|
Doubtful.. I would imagine they run just the same. If all you're doing is changing the appearance of the code, variable names, etc., the parser isn't going to have any problem with it, and the resulting bytecode will be indistinguishable. If, however, you're encoding your strings, doing some unusual looping or whatever, you're going to incur some slight penalties if a lot of work normally done at compile time is going to be done (esp. repetitively) at run-time. It all depends on how you go about doing it.
| [reply] |
|
|
This was my thought as well, but some cool tricks look to me somewhat like obfuscated.
So I might redefine: How obfuscated is effective perl?
Have a nice day
All decision is left to your taste
| [reply] |
|
|
|
|
Ever read any really highly optimized code? In assmebly perhaps? Some methods like intentionally overflowing, stuff like that? Passing pointers in odd ways. Lots of stuff like that makes code almost unreadable, but can make it MUCH faster. Look at the goto statement! I have heard of old computers that move through data structures quickly by cycling to the end of drum memory, and then cycling foward one to arrive at the head again. Try a full time job maintaining old code, designed on old machines. Almost impossibly to read, but HIGHLY tuned and INCREDIBLY efficient. They used to fit everything in less than 16K on high end computers, and did some pretty crazy cramming to make it work.
Just Another Perl Backpacker
| [reply] |
|
|
I can't vouch for the accuracy of Mel in the aforementioned story, but I can tell you that drum tuning was a *very* common practice. Other than Mel getting the sense switch backwards, all the tuning information is probable.
There are a couple of machines that have some really cool instructions. The old Data General Nova systems had an indexed fetch instruction that if the high bit was set, would use the contents of the fetched data as another index. If the high bit was set, this would repeat. It made finding the end of a linked list pretty trivial. It could also make a pretty effective endless loop. With the Nova 1200 system we... acquired... we taught it to play the "Daisy, Daisy, Give me your answer true" melody by tuning loops that made the core memory planes "sing". If I run across my 8K x 16 core memory plane, I'll take a picture and post it. Hand woven by oriental women.
Another interesting instruction was on the Control Data Corporation Cyber systems. At the request of the Atomic Energy Comission, an instruction was added that would return the number of bits set it a word (these were 60 bit words). This was used in some nuclear bomb simulation calcuations.
One free ++ to anyone who figures out what this code does, and explains why:
and al,00fh
add al,090h
daa
adc al,040h
daa
The actual instruction set is irrelevant, but that's x86 code.
--Chris
e-mail jcwren | [reply]
[d/l] |
|
|
|
|
|
|
|
|
|
|
this is just haker's folklore, maybe you was too impressed by
this story...
| [reply] |
|
|
|
|