Re: The situation at hand and in the future

[David Masover <ninja@slaphack.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Valdis.Kletnieks@vt.edu wrote:
[...]
| Proper programming would probably render encryption almost-zero overhead.
| Except for really high-end disk subsystems, you're not going to get an
*effective*
| (i.e. after seeks and rotational delay and all that) throughput of
much over
| 40 megabytes/second - and encrypting/decrypting at 40 megabytes/second

Yes, I know this.  Consider:  On Windows 9x (and 3.1, of course), when
you read from a floppy, it's unbelievably slow.  True, this doesn't
matter much when you consider how slow the physical medium is.  But
while it's actually reading it, you cannot do anything else.

So, multitasking matters.  Suppose I've got this game (because games are
fun) with two threads -- the player-kills-all thread, and the
load-rest-of-level thread.  So the player isn't going to move for awhile
- -- he's getting shot at too much -- but the game wants to load a little
more detail from disk to make the sky and/or landscape look prettier.
Without encryption, big deal -- the level-loading thread asks for the
data from the disk, then goes to sleep until it arrives, thus freeing
resources for the immediate gameplay.  With encryption, if we are trying
to load things from disk, we are also going to have to spend some CPU
decrypting them which we wouldn't otherwise.  Not much latency -- unless
you need CPU to make sure the player doesn't lag.  Or you put the thread
on a low priority, which works -- unless you need as close to 100% CPU
as possible for higher-priority threads, which drives said latency up
insanely.

Of course, most of the time people can just buy a new CPU.

Should we take this off-list?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQMeIrXgHNmZLgCUhAQJLkhAAj97ah2lvz97mmtVFvydmZ+nJPS1f/OBP
gifHHcE8ZGe/PN2Iy+1PQVz2P1GkDmk2dW8/HIid+aHYv0UZsISw6Y6rQ2Kyxr9y
OULkebG+qgV5zxwKFUMKqkTMaxFXJBQinxvf1mdEbOMmTfxW1HzKB7FYVH3muAWO
i4knab6t720m+rWQ0q+VBKKSH52CVHCno1ncZnaRiTmZlicJQ3GSitglq/5NHsk6
3PKPXM68TMWl7ms9k6Htseba3jYcW4l9kHNjHICjAbQ4hK/KYtkNhoBeTIoVcpbW
BkGa9ThKF23/3CTYNycXZ+BUS6C7RdH9iXku5WjlbrT6dlEZDDenleiJz5HEBo94
MB74xlGLpz2O/b/A/i0iie5QJyoyOzexqh+AMoJlN9n6VUS1o5sUquoDWPhL9ZvH
1BUJnm/tk9qcOuzmkcxux0sWVGambqJah9gU8F+a0AQTiT71z4UnEb78YmWfQFg7
hXsWgXG2l/aF8XKqQY4w+lZT2WsX7kcSZ417VzeoiMVx1yHpYQk2qPDC59n8EcNh
q1EmNaYJD0DEtAbexH5jZhlofB9mnpJDpRHPvixKDxvD5h7WLrcwyfJ7+SHZnykw
xUDXRumoWmF2La/Dh75SwQc6YJeyXVmOICB6uRuX7mC187wjfQfy/KC2Z6dRjNow
ysMN5rbtSLY=
=Ayvm
-----END PGP SIGNATURE-----