| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
|
| 5 |
|
| 6 |
Spider wrote: |
| 7 |
| begin quote |
| 8 |
|
| 9 |
[...] |
| 10 |
|
| 11 |
| Can somone take the time to benchmark this properly though? we rather |
| 12 |
| shouldn't have many "oh this sucks 15% cpu" rumours without substance. |
| 13 |
| both string and integer, small and large software. |
| 14 |
| |
| 15 |
|
| 16 |
The more I think about benching SSP, the less I like the idea. It's |
| 17 |
pretty much impossible to create a solid benchmark for SSP. |
| 18 |
|
| 19 |
With things like -O2, the way the code is generated is affected fairly |
| 20 |
genericly. Optimization levels throw in a lot of changes which produce |
| 21 |
overall a pretty reliable performance difference. |
| 22 |
|
| 23 |
With other things like -fpic, -fomit-frame-pointer, or -mfpmath=387, the |
| 24 |
changes are a bit different. -fpic alters the way instructions find |
| 25 |
functions and global variables; -fomit-frame-pointer makes certain bits |
| 26 |
of function calls change; and -mfpmath=387 strictly affects floating |
| 27 |
point math. These are fairly specific changes, but generalyl affect a |
| 28 |
large chunk of code and can be measured pretty well. |
| 29 |
|
| 30 |
SSP doesn't modify code, it adds it and shifts it around. It finds |
| 31 |
"vulnerable looking" functions based on some heuristic, inserts |
| 32 |
protection code in the beginning, and a guard evaluation at the end. It |
| 33 |
moves local variables around to not let arrays clobber other things, and |
| 34 |
copies passed arguments to new local variables. Depending on how many |
| 35 |
of such functions it finds, how often they're called, and yes how BIG |
| 36 |
they are, the performance hit varies. It's VERY hard to quantify |
| 37 |
generically. |
| 38 |
|
| 39 |
| Some of the more interesting parts would be fex. python performance and |
| 40 |
| performance of python apps. |
| 41 |
|
| 42 |
Again, hard to quantify generically. I'm sure certain python operations |
| 43 |
will cause SSP to go happy-gilmore on you; process a string 8 billion |
| 44 |
times in a tight loop for example. Something in the python interpreter |
| 45 |
probably has a vulnerable looking function (i.e. a function with a local |
| 46 |
character pointer) and does very little with the string. |
| 47 |
|
| 48 |
I don't know how Python is coded. It uses 'compiled' .py objects, |
| 49 |
right? Bytecode interpreters probably wouldn't take as big a hit as |
| 50 |
straight interpreters that process assloads of strings; I may be wrong, |
| 51 |
the interpreters may have char[] arrays in their functions and use tiny, |
| 52 |
rapidly called functions :) |
| 53 |
|
| 54 |
In any case, I never notice. Your mileage may vary. |
| 55 |
|
| 56 |
| |
| 57 |
| //Spider |
| 58 |
| |
| 59 |
| |
| 60 |
|
| 61 |
- -- |
| 62 |
All content of all messages exchanged herein are left in the |
| 63 |
Public Domain, unless otherwise explicitly stated. |
| 64 |
|
| 65 |
-----BEGIN PGP SIGNATURE----- |
| 66 |
Version: GnuPG v1.2.6 (GNU/Linux) |
| 67 |
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org |
| 68 |
|
| 69 |
iD8DBQFBVEG4hDd4aOud5P8RAkCOAJ9LPLYze3pljX1VXbeToH9wJlYkywCfVPJ/ |
| 70 |
sT9MzpFJ2pOZ60XmTyB3pwo= |
| 71 |
=DFUc |
| 72 |
-----END PGP SIGNATURE----- |
| 73 |
|
| 74 |
-- |
| 75 |
gentoo-dev@g.o mailing list |
Archives