If you need help with how to do this succesfully, talk to "Carlo Wood". This person, whoever he/she is, has contributed to GCC, various GNU utilities, and lots of other projects. He also shows up on mailing lists pretty often. Anyway, basically he signs everything with PGP; if at some point he has to reveal his true identity, he can show that he knows the private key to prove that he is Carlo Wood.
It's based around the idea that you can sign something with a digital signature without seeing what that something is. They're called blind signatures. From this technique, you can build up digital cash with the following properities (and more):
1) It's anonymous. I can go to the bank, say "Give me $100 of digital cash". They deduct $100 from my account, and give me $100 worth of digital cash. I can spend this money later, and nobody; not the bank, not the merchant, and not both of them working together, can figure out who it was that spent the money. They will also not be able to coorelate purchases (bought Foo last week and Bar yesterday, etc). It is completely anonymous, just like you walked in and paid cash.
2) Can't cheat. Of course, digital cash is just bits. But if I try to use the same piece of digital cash twice, the bank can figure out who I am (with 100% probability). If the merchant tries to deposit the same piece of cash twice, the bank will know it was the merchant that is cheating, and will still be unable to figure out my identity.
The techniques are fairly simple, but do require a good bit of crypto background. I'm not such a huge fan of the book "Applied Cryptography", but it's easy to find and IIRC walks through the whole protocol in a pretty easy to understand way.
Actually, the stuff that I want to watch (and is not already owned by me or someone I live with) all comes on early, so by 11:30/midnight we can all go out and get hammered at a party or a dump bar.
unless, of course, it's dubbed so terribly that all the characters are somehow dull and obnoxious at the same time.
No worries: the dub is quite well done. Except for the old lady (whatever her name is, I always forget). I presume in the orginal she spoke in an antiquitated/country dialect, but in the English she sounds like she's just a nutty fan of Shakespeare or something (thees and thous all over the place). But Inu Yasha, Kagome, that weird flea, etc are all well done.
I tend to dislike Gundam as well. However, G Gundam (it's been running in the afternoons of late), is actually not half bad, mostly because the writers were obviously insane. ["It's the American's most powerful weapon: The Statue of Liberty Cannon!" (cut to shot of McArthur look alike, complete with corncob pipe, about to fire the cannon at the Japanese)]. It's dumb, but funny-dumb.
I went to a university that refused to teach product specific stuff. We we were taught to code C on sunos and solaris with gcc in the intro classes.
That's pretty much how my university experience went. I came out a lot better for it too. It's a good learning experience to be given a reference to some tutorial material and told "Learn this language by the beginning of next week".
The distributed.net core uses the Altivec SIMD extension on the G4, which has a useless rotate instruction, which serves absolutely no purpose that I know of on anything other than RC5 encryption.
I'll admit I don't know Altivec too well. But I can pretty much guarantee you that a SIMD rotate instruction would be fairly handly on a reasonable number of crypto algorithms (RC6 and MARS come immediately to mind). Assuming it's doing what I figure it's doing based on your statement.
BTW, SIMD is useful in some crypto algorithms. In particular, I'm thinking of UMAC16, which was designed to be used with MMX or AltiVec. Yes, it most sitiations it's hard or impossible to run the high-level operations in parallel (though you can with Counter mode and when decrypting CBC -- they can both be done infinitely in parallel). And some algorithms do have operations internally that can be implemented with SIMD (mostly by design).
And no, just hoping everyone's going to be running 64-bit systems by then is not going to help if you have, for example, file formats which only allocate 4 bytes to storing a time_t value.
Most file formats that I've seen (such as OpenPGP), define the time as a 4 byte UNSIGNED value, which will work until 2106 (if I'm calculating that correctly). The odds that any file formats today will be in use by then is pretty freaking small. Anyway, I'll be 125 (long retired or long dead) at that point, so I'm not worried.
In fact there is no problem with defining time_t as an unsigned int. time()'s is defined as returning (time_t)-1 on error -- this works regardless of time_t's signedness.
The first is key generation. No matter how simple of a front end you have for it, the user still has to consciously sit down and create a strong key. We all know from experience that the average user will not want to do this.
The second is even more problematic. That's key management. Where is the average user going to store their private keys? On their harddrive or on a floppy disk? And will they be conscientious participants in a web of trust?
These are good points. But, realistically, there is a very easy solution around both of these: ignore the problem altogether.
Yup, seriously. If 10% of the population was sending email encrypted with even a 512-bit RSA key that's sitting unencrypted on their disk, that's a whole lotta traffic (and it makes it much easier to hide the important stuff that you've got encrypted with a 1024-2048 bit key).
Generate the key without a passphrase when the user creates a profile (of course allow setting one if the user wants). The simple fact is that, in such a setup, the person cannot possibly be in any worse a situation than before. Sure, you could get ahold of their key (for which you need local access) and read their mail, whereas before, you just read their mail directly (either off the disk or over the network). Attacks over the network (taps at your ISP, etc) are much cheaper (and thus much more likely) than a black bag job on your machine.
Web of trust is pretty hard, but you can fake it fairly easily by, for example, storing the PGP keyid in an X- header in all outgoing email (both encrypted and cleartext stuff). It's not failsafe, but it's workable. It's actually a good secondary method anyway, I've had my PGP keyid set in the headers of my outgoing mail since at least last year sometime. I get an email from you, my software looks for such a header, gets the key from a keyserver, and starts encrypting anything I send to you in the future.
Certainly, it's quite spoofable. But even after the required active attack of sending you mail with faked headers, they would have to intercept the email you respond with, decrypt it, send the decrypted version to the recipient while ensuring they don't get the encrypted version, etc, etc.
You can make it a bit harder by requiring (say) 10 messages over the course of at least 5 days with the same keyid before accepted that keyid as the one for their real key. Of course none of what I'm suggesting here is perfect. But IMO the gains from it are large enough that such a thing is more than worthwhile.
If you want to see how tracking your config from CVS would look, the BSD folks have the entire source for their systems in CVS.
<SHAMELESS PLUG> You might also try OpenCM for this. </SHAMELESS PLUG>
Todd Fries of the OpenBSD project has been working on OpenCM quite a bit, and hopefully someday fairly soon (by which I mean a year if we're lucky), OpenBSD will be using OpenCM instead of CVS.
It sounds kind of sissy, but iced black tea is: (list of good things about tea)
I would like to second you on this one. Tea is good. Real good. Your points, particularly (a), (b), and (e), are right on the money. Since I brew it strong and add lots of sugar, (c) and (d) don't really count for my tea (even still, I'm sure it has far less sugar than Mt. Dew)
Back in my freshman year, my mom sent me a huge box of Lipton tea. 4 years later, I still have about half of it. And Lipton tea gives me a stomache ache (bad) if I drink it hot. So making lots and lots of iced tea is about the only way for me to get rid of it.
For any Tenchi fans out there: Take a bottle. Write "BAD TEA" on it. Fill with actual tea. Amuse your geeky anime friends. (If you haven't seen the edited American TV version you will have no idea what I'm talking about here).
Somehow somebody got confused and thought that this meant that the TCP stack was from BSD, when it's a complete custom job.
OK. That makes more sense. It always seemed to me to be a rather dangerous game to play -- if someone found out MS was using OBSD's TCP stack (and proved it), OpenBSD could do some pretty amusing press releases (OpenBSD powers next generation of Windows servers!).
Well, the BSD license says that the license/attribution notice must stay with the code and its derivatives, but since you don't necessarily have a right to look at BSD-derived code, and there's nothing about using preprocessor directives to eliminate the comments from the binary, there's no way to know.
But the license says:
* 2. Redistributions in binary form must reproduce the above
* copyright notice, this list of conditions and the following
* disclaimer in the documentation and/or other materials
* provided with the distribution.
Roughly, at least. (I just copied this out of a header at work I'm supposed to be working on.) If it's a binary only distribution, and they don't include the copyright notices and a copy of the license, they're violating the license.
I'm sure it happens a lot, but it's just as illegal as selling GPLed software without giving out the source (or making copies of Windows XP).
he recalls seeing some files working at MS that were BSD-licensed code, and IIRC the license notice wasn't actually stripped out, but it had been taken out of context and slapped down at the bottom of the file, in a not-likely-to-be-read place.
Yeah, some of the headers included with Visual C++ have BSD copyrights on them as well (usually down at the end). They do the same when they're using a third-party library. IIRC much of their ANSI C/C++ library was done by P.J. Plauger (sp?), they moved all his (C)'s to the end of the file and put a (C) Microsoft up at the top.
It doesn't seem very polite, but OTOH it does comply with the license. Much preferable to removing the notices.
but the licence, being Bill Gates' wet dream, allows for this, right?
IF you include the original license along with your software. I was looking at some page (IIRC linked off the zlib website) showing products using zlib. Often (mostly on commercial Windows apps) there is an additional note: (copyright notice removed). They don't explain exactly what this means, but I suspect removing such a notice violates the license.
ISTR back when W2K was released there were allegations that it used OpenBSD's TCP/IP stack without attribution. I can't remember how that ever turned out, though.
People running big compiles a lot want it. I've got a 1.4 Ghz Athlon at home, I probably spend something around an hour a day just sitting around waiting for compiles to complete. That wait is almost completely CPU bound -- double the speed of the CPU, compile time cuts in half.
At work, my 933 Mhz P-III, pretty much the same situation. Compiles take 10 minutes. The test suite takes about 15 minutes. This is dead time.
Oh, I agree, for a small server or running Office, or even playing most games, you don't need much beyond a 400 or 600 Mhz CPU. But there are plenty of people out there who can use every cycle they can get.
Gee, the whole article sounds like a lame press release. I want the real low down, not a marketing piece!
You may want to avoid hardwareextreme, then. I knew I shouldn't even have bothered reading this one. I've never read a thing there that wasn't "written" in the same style (ie, copy a bunch of press releases and call yourself a hardware site).
it's the only compiler I've used that I haven't yet found a bug in.
I actually found 3 or 4 bugs in it (back in the 3.4 versions). Which was a pleasurable experience in itself, because each time, they had a fixed version for me within 48 hours. That impressed me very much.
Yes. This is an excellent suggestion. I practice a lot with a bokuto; this is nice because I can do it pretty much anywhere, I can practice alone or with someone, and it's fun. I'M A NINJA! Or something...
Hey! You're a JHUian. A CS JHUian! WTF? And your UID on barley is only 20 off from mine, too. Are you in one of the clubs hosted by JHU, or one of the CV area ones?
Re:Any good compilers out there.
on
GCC 3.2 Released
·
· Score: 1
I'd like to see a real benchmark of this. The same exact thing is said about every language/compiler by its proponents (think java vs c/c++, etc)...
here is a link to some comparisons I made. It's kind of out of date, GCC 3.0.4 vs ICC 6.0 vs KAI C++ 4.0e. I'm using 3.1.1 as my usual compiler nowadays but I haven't gotten around to updating this.
Basically the poster you responded to is right. ICC won on some things, GCC won on others. And, for the most part, KAI C++ kicked the hell out of both of them. The comparison was integer-heavy code with lots of tight loops on a 1.4 Ghz Thunderbird.
Re:What does this mean for OS X?
on
GCC 3.2 Released
·
· Score: 1
This is really bad timing for Apple folks.
Nope. Various Apple people said on the lists that they were happy with 3.1.1.
1. Massively expanding address space and hence (for the first time - IMHO) making the holy grail of direct manipulation of persistent data structures a realistic proposition.
Well, EROS does just this on 32 bit systems. (Thankfully), I haven't had to touch EROS much yet, so I don't really know how it handles it, though.
Of course, given there is no driver for hard drives, etc (and last I heard booting the kernel didn't work on systems with more than 256 megs of memory), the fact that it supports persistent state is not particularly useful. But someday...
2. Expanding the size of today's simple data structures. Consider, for example, a simple bi-directional linked list of 32-bit integers using a forwards and backwards pointer. A 32 bit arch has a 200% overhead, but 64 bit ach has 400% which should somewhat diminish expectations for magical performance!
That's just a bad data structure. What you want is to have each node of the linked list have a fixed size array (say 1-16K, depending on local circumstances), and a couple of extra integers telling you where the start and stop of the arrays are. This is much, must faster, and the memory overhead for the extra pointers (be they 32 or 64 bits) is quite small. It's also quite trivial to program.
Excuse me, the data structure I just described is for queues, not general lists (queues tend to come up more often than list for me so that's what my mind jumped to, I guess). But you see my point, I hope.
I can't really think of a case where a 400% overhead is too much, but 200% is OK.
If Fortran wins - I would assume the win is because the restrictiveness and explicitness of the language make it easier for an optimizer to *really* know what's going and how to optimize things away safely.
You are exactly correct here. One of the big reasons Fortran can be faster than C/C++ is that aliasing has to be explicit in Fortran. For example:
void foo(double* x, const double* y,
const double* z, int size) { int j; for(for j = 0; j != size; j++)
x[j] += *y * z[j]; }
A C compiler can't tell if x, y, and z are the same pointer, overlapping, or some other weird combination that might cause problems, so it can't optimize as well. For example if y == x + 5, many obvious loop unrolling and vectorization optimzations don't work correctly.
The 'restrict' keyword is claimed to solve a lot of these problems, but I've found, looking at the generated code, it doesn't make too much of a difference. Maybe someday compilers will be able to handle it better.
I've done it. It was a @!#$% to debug the first time around: every time I dropped into sash everything worked, but if I didn't drop into sash it didn't.:-)
Ah, good times messing with free Unix systems.:)
This is totally offtopic to the article. I just thought of a little story that was somewhat related to yours. Once, long ago (OK, 4 or 5 months ago) hacking the Linux VM for an OS class. An editing error (I cut some code to move it around, and ended up pasting it twice in two different spots) completely broke shared libraries (I think I may have disabled major portions of the copy on write semantics of fork, actually). Booting the system, even in single user mode, failed in fairly obscure way (init said "No more processes at this runlevel" and just sat there). Of course booting with init=/bin/sash worked very nicely.
Your story just made me think about this, and I felt like 'sharing'. (Awww...)
Schneier, "Applied Cryptography" -- this is a must have if you ever do any type of crypto work, from munging files to hard encryption.
Better (IMO) is Handbook of Applied Cryptography, by Menezes, van Oorschot, and Vanstone. Also Stinson's book (titled Cryptography, Theory and Practice IIRC). AC is an OK-ish book but there really are a lot of errors in it.
HAC is avaiable online in PDF and PostScript, so there's little excuse not to read it.
Re:Why does the ABI keep changing?
on
GCC 3.1.1 Released
·
· Score: 3, Interesting
But now there's going to be a release incompatible with 3.0/3.1? Come *on*, guys!
And 3.2 is compatible with the V3 ABI. Sure, they could just keep the current ABI, and remain incompatible with compilers from Intel and other commercial vendors forever. That doesn't seem like a particularly great path to me, though.
The reason 3.2 is coming out a few days after 3.1.1 is so RedHat, Mandrake, FreeBSD, SuSE, etc can have time to QA it for their next releases. I don't know of any distributions using 3.0 or 3.1 anyway. Debian and *BSD are still on 2.95.x, Redhat/Mandrake are 3.0-beta. Not sure about SuSE though. So, basically, it's not as if the 3.{0,1}/3.2 ABI changes actually affect anyone, because while 3.2 is incompatible with previous 3.0 releases, 3.2 and 3.0/3.1 are "equally incompatible" with whatever the systems are using now.
Slashdot Mirror
If you need help with how to do this succesfully, talk to "Carlo Wood". This person, whoever he/she is, has contributed to GCC, various GNU utilities, and lots of other projects. He also shows up on mailing lists pretty often. Anyway, basically he signs everything with PGP; if at some point he has to reveal his true identity, he can show that he knows the private key to prove that he is Carlo Wood.
so could you summarize what the magic is? Thanks.
It's based around the idea that you can sign something with a digital signature without seeing what that something is. They're called blind signatures. From this technique, you can build up digital cash with the following properities (and more):
1) It's anonymous. I can go to the bank, say "Give me $100 of digital cash". They deduct $100 from my account, and give me $100 worth of digital cash. I can spend this money later, and nobody; not the bank, not the merchant, and not both of them working together, can figure out who it was that spent the money. They will also not be able to coorelate purchases (bought Foo last week and Bar yesterday, etc). It is completely anonymous, just like you walked in and paid cash.
2) Can't cheat. Of course, digital cash is just bits. But if I try to use the same piece of digital cash twice, the bank can figure out who I am (with 100% probability). If the merchant tries to deposit the same piece of cash twice, the bank will know it was the merchant that is cheating, and will still be unable to figure out my identity.
The techniques are fairly simple, but do require a good bit of crypto background. I'm not such a huge fan of the book "Applied Cryptography", but it's easy to find and IIRC walks through the whole protocol in a pretty easy to understand way.
Actually, the stuff that I want to watch (and is not already owned by me or someone I live with) all comes on early, so by 11:30/midnight we can all go out and get hammered at a party or a dump bar.
unless, of course, it's dubbed so terribly that all the characters are somehow dull and obnoxious at the same time.
No worries: the dub is quite well done. Except for the old lady (whatever her name is, I always forget). I presume in the orginal she spoke in an antiquitated/country dialect, but in the English she sounds like she's just a nutty fan of Shakespeare or something (thees and thous all over the place). But Inu Yasha, Kagome, that weird flea, etc are all well done.
I tend to dislike Gundam as well. However, G Gundam (it's been running in the afternoons of late), is actually not half bad, mostly because the writers were obviously insane. ["It's the American's most powerful weapon: The Statue of Liberty Cannon!" (cut to shot of McArthur look alike, complete with corncob pipe, about to fire the cannon at the Japanese)]. It's dumb, but funny-dumb.
I went to a university that refused to teach product specific stuff. We we were taught to code C on sunos and solaris with gcc in the intro classes.
That's pretty much how my university experience went. I came out a lot better for it too. It's a good learning experience to be given a reference to some tutorial material and told "Learn this language by the beginning of next week".
The distributed.net core uses the Altivec SIMD extension on the G4, which has a useless rotate instruction, which serves absolutely no purpose that I know of on anything other than RC5 encryption.
I'll admit I don't know Altivec too well. But I can pretty much guarantee you that a SIMD rotate instruction would be fairly handly on a reasonable number of crypto algorithms (RC6 and MARS come immediately to mind). Assuming it's doing what I figure it's doing based on your statement.
BTW, SIMD is useful in some crypto algorithms. In particular, I'm thinking of UMAC16, which was designed to be used with MMX or AltiVec. Yes, it most sitiations it's hard or impossible to run the high-level operations in parallel (though you can with Counter mode and when decrypting CBC -- they can both be done infinitely in parallel). And some algorithms do have operations internally that can be implemented with SIMD (mostly by design).
And no, just hoping everyone's going to be running 64-bit systems by then is not going to help if you have, for example, file formats which only allocate 4 bytes to storing a time_t value.
Most file formats that I've seen (such as OpenPGP), define the time as a 4 byte UNSIGNED value, which will work until 2106 (if I'm calculating that correctly). The odds that any file formats today will be in use by then is pretty freaking small. Anyway, I'll be 125 (long retired or long dead) at that point, so I'm not worried.
In fact there is no problem with defining time_t as an unsigned int. time()'s is defined as returning (time_t)-1 on error -- this works regardless of time_t's signedness.
The first is key generation. No matter how simple of a front end you have for it, the user still has to consciously sit down and create a strong key. We all know from experience that the average user will not want to do this.
The second is even more problematic. That's key management. Where is the average user going to store their private keys? On their harddrive or on a floppy disk? And will they be conscientious participants in a web of trust?
These are good points. But, realistically, there is a very easy solution around both of these: ignore the problem altogether.
Yup, seriously. If 10% of the population was sending email encrypted with even a 512-bit RSA key that's sitting unencrypted on their disk, that's a whole lotta traffic (and it makes it much easier to hide the important stuff that you've got encrypted with a 1024-2048 bit key).
Generate the key without a passphrase when the user creates a profile (of course allow setting one if the user wants). The simple fact is that, in such a setup, the person cannot possibly be in any worse a situation than before. Sure, you could get ahold of their key (for which you need local access) and read their mail, whereas before, you just read their mail directly (either off the disk or over the network). Attacks over the network (taps at your ISP, etc) are much cheaper (and thus much more likely) than a black bag job on your machine.
Web of trust is pretty hard, but you can fake it fairly easily by, for example, storing the PGP keyid in an X- header in all outgoing email (both encrypted and cleartext stuff). It's not failsafe, but it's workable. It's actually a good secondary method anyway, I've had my PGP keyid set in the headers of my outgoing mail since at least last year sometime. I get an email from you, my software looks for such a header, gets the key from a keyserver, and starts encrypting anything I send to you in the future.
Certainly, it's quite spoofable. But even after the required active attack of sending you mail with faked headers, they would have to intercept the email you respond with, decrypt it, send the decrypted version to the recipient while ensuring they don't get the encrypted version, etc, etc.
You can make it a bit harder by requiring (say) 10 messages over the course of at least 5 days with the same keyid before accepted that keyid as the one for their real key. Of course none of what I'm suggesting here is perfect. But IMO the gains from it are large enough that such a thing is more than worthwhile.
If you want to see how tracking your config from CVS would look, the BSD folks have the entire source for their systems in CVS.
<SHAMELESS PLUG>
You might also try OpenCM for this.
</SHAMELESS PLUG>
Todd Fries of the OpenBSD project has been working on OpenCM quite a bit, and hopefully someday fairly soon (by which I mean a year if we're lucky), OpenBSD will be using OpenCM instead of CVS.
It sounds kind of sissy, but iced black tea is: (list of good things about tea)
I would like to second you on this one. Tea is good. Real good. Your points, particularly (a), (b), and (e), are right on the money. Since I brew it strong and add lots of sugar, (c) and (d) don't really count for my tea (even still, I'm sure it has far less sugar than Mt. Dew)
Back in my freshman year, my mom sent me a huge box of Lipton tea. 4 years later, I still have about half of it. And Lipton tea gives me a stomache ache (bad) if I drink it hot. So making lots and lots of iced tea is about the only way for me to get rid of it.
For any Tenchi fans out there: Take a bottle. Write "BAD TEA" on it. Fill with actual tea. Amuse your geeky anime friends. (If you haven't seen the edited American TV version you will have no idea what I'm talking about here).
Because Jim Jones and the People's Temple did not drink Grape Kool-Aid, but cyanide laced Flavor-Aid, a cheap Kool-Aid rip off.
Never trust someone who doesn't drink the Real Stuff, that's my motto.
Somehow somebody got confused and thought that this meant that the TCP stack was from BSD, when it's a complete custom job.
OK. That makes more sense. It always seemed to me to be a rather dangerous game to play -- if someone found out MS was using OBSD's TCP stack (and proved it), OpenBSD could do some pretty amusing press releases (OpenBSD powers next generation of Windows servers!).
Well, the BSD license says that the license/attribution notice must stay with the code and its derivatives, but since you don't necessarily have a right to look at BSD-derived code, and there's nothing about using preprocessor directives to eliminate the comments from the binary, there's no way to know.
But the license says:
* 2. Redistributions in binary form must reproduce the above
* copyright notice, this list of conditions and the following
* disclaimer in the documentation and/or other materials
* provided with the distribution.
Roughly, at least. (I just copied this out of a header at work I'm supposed to be working on.) If it's a binary only distribution, and they don't include the copyright notices and a copy of the license, they're violating the license.
I'm sure it happens a lot, but it's just as illegal as selling GPLed software without giving out the source (or making copies of Windows XP).
he recalls seeing some files working at MS that were BSD-licensed code, and IIRC the license notice wasn't actually stripped out, but it had been taken out of context and slapped down at the bottom of the file, in a not-likely-to-be-read place.
Yeah, some of the headers included with Visual C++ have BSD copyrights on them as well (usually down at the end). They do the same when they're using a third-party library. IIRC much of their ANSI C/C++ library was done by P.J. Plauger (sp?), they moved all his (C)'s to the end of the file and put a (C) Microsoft up at the top.
It doesn't seem very polite, but OTOH it does comply with the license. Much preferable to removing the notices.
but the licence, being Bill Gates' wet dream, allows for this, right?
IF you include the original license along with your software. I was looking at some page (IIRC linked off the zlib website) showing products using zlib. Often (mostly on commercial Windows apps) there is an additional note: (copyright notice removed). They don't explain exactly what this means, but I suspect removing such a notice violates the license.
ISTR back when W2K was released there were allegations that it used OpenBSD's TCP/IP stack without attribution. I can't remember how that ever turned out, though.
But for the rest of us, who really needs it?
People running big compiles a lot want it. I've got a 1.4 Ghz Athlon at home, I probably spend something around an hour a day just sitting around waiting for compiles to complete. That wait is almost completely CPU bound -- double the speed of the CPU, compile time cuts in half.
At work, my 933 Mhz P-III, pretty much the same situation. Compiles take 10 minutes. The test suite takes about 15 minutes. This is dead time.
Oh, I agree, for a small server or running Office, or even playing most games, you don't need much beyond a 400 or 600 Mhz CPU. But there are plenty of people out there who can use every cycle they can get.
Gee, the whole article sounds like a lame press release. I want the real low down, not a marketing piece!
You may want to avoid hardwareextreme, then. I knew I shouldn't even have bothered reading this one. I've never read a thing there that wasn't "written" in the same style (ie, copy a bunch of press releases and call yourself a hardware site).
it's the only compiler I've used that I haven't yet found a bug in.
I actually found 3 or 4 bugs in it (back in the 3.4 versions). Which was a pleasurable experience in itself, because each time, they had a fixed version for me within 48 hours. That impressed me very much.
Look for a local martial arts club.
Yes. This is an excellent suggestion. I practice a lot with a bokuto; this is nice because I can do it pretty much anywhere, I can practice alone or with someone, and it's fun. I'M A NINJA! Or something...
Hey! You're a JHUian. A CS JHUian! WTF? And your UID on barley is only 20 off from mine, too. Are you in one of the clubs hosted by JHU, or one of the CV area ones?
here is a link to some comparisons I made. It's kind of out of date, GCC 3.0.4 vs ICC 6.0 vs KAI C++ 4.0e. I'm using 3.1.1 as my usual compiler nowadays but I haven't gotten around to updating this.
Basically the poster you responded to is right. ICC won on some things, GCC won on others. And, for the most part, KAI C++ kicked the hell out of both of them. The comparison was integer-heavy code with lots of tight loops on a 1.4 Ghz Thunderbird.
This is really bad timing for Apple folks.
Nope. Various Apple people said on the lists that they were happy with 3.1.1.
1. Massively expanding address space and hence (for the first time - IMHO) making the holy grail of direct manipulation of persistent data structures a realistic proposition.
Well, EROS does just this on 32 bit systems. (Thankfully), I haven't had to touch EROS much yet, so I don't really know how it handles it, though.
Of course, given there is no driver for hard drives, etc (and last I heard booting the kernel didn't work on systems with more than 256 megs of memory), the fact that it supports persistent state is not particularly useful. But someday...
2. Expanding the size of today's simple data structures. Consider, for example, a simple bi-directional linked list of 32-bit integers using a forwards and backwards pointer. A 32 bit arch has a 200% overhead, but 64 bit ach has 400% which should somewhat diminish expectations for magical performance!
That's just a bad data structure. What you want is to have each node of the linked list have a fixed size array (say 1-16K, depending on local circumstances), and a couple of extra integers telling you where the start and stop of the arrays are. This is much, must faster, and the memory overhead for the extra pointers (be they 32 or 64 bits) is quite small. It's also quite trivial to program.
Excuse me, the data structure I just described is for queues, not general lists (queues tend to come up more often than list for me so that's what my mind jumped to, I guess). But you see my point, I hope.
I can't really think of a case where a 400% overhead is too much, but 200% is OK.
If Fortran wins - I would assume the win is because the restrictiveness and explicitness of the language make it easier for an optimizer to *really* know what's going and how to optimize things away safely.
You are exactly correct here. One of the big reasons Fortran can be faster than C/C++ is that aliasing has to be explicit in Fortran. For example:
void foo(double* x, const double* y,
const double* z, int size)
{
int j;
for(for j = 0; j != size; j++)
x[j] += *y * z[j];
}
A C compiler can't tell if x, y, and z are the same pointer, overlapping, or some other weird combination that might cause problems, so it can't optimize as well. For example if y == x + 5, many obvious loop unrolling and vectorization optimzations don't work correctly.
The 'restrict' keyword is claimed to solve a lot of these problems, but I've found, looking at the generated code, it doesn't make too much of a difference. Maybe someday compilers will be able to handle it better.
I've done it. It was a @!#$% to debug the first time around: every time I dropped into sash everything worked, but if I didn't drop into sash it didn't. :-)
:)
Ah, good times messing with free Unix systems.
This is totally offtopic to the article. I just thought of a little story that was somewhat related to yours. Once, long ago (OK, 4 or 5 months ago) hacking the Linux VM for an OS class. An editing error (I cut some code to move it around, and ended up pasting it twice in two different spots) completely broke shared libraries (I think I may have disabled major portions of the copy on write semantics of fork, actually). Booting the system, even in single user mode, failed in fairly obscure way (init said "No more processes at this runlevel" and just sat there). Of course booting with init=/bin/sash worked very nicely.
Your story just made me think about this, and I felt like 'sharing'. (Awww...)
Schneier, "Applied Cryptography" -- this is a must have if you ever do any type of crypto work, from munging files to hard encryption.
Better (IMO) is Handbook of Applied Cryptography, by Menezes, van Oorschot, and Vanstone. Also Stinson's book (titled Cryptography, Theory and Practice IIRC). AC is an OK-ish book but there really are a lot of errors in it.
HAC is avaiable online in PDF and PostScript, so there's little excuse not to read it.
But now there's going to be a release incompatible with 3.0/3.1? Come *on*, guys!
And 3.2 is compatible with the V3 ABI. Sure, they could just keep the current ABI, and remain incompatible with compilers from Intel and other commercial vendors forever. That doesn't seem like a particularly great path to me, though.
The reason 3.2 is coming out a few days after 3.1.1 is so RedHat, Mandrake, FreeBSD, SuSE, etc can have time to QA it for their next releases. I don't know of any distributions using 3.0 or 3.1 anyway. Debian and *BSD are still on 2.95.x, Redhat/Mandrake are 3.0-beta. Not sure about SuSE though. So, basically, it's not as if the 3.{0,1}/3.2 ABI changes actually affect anyone, because while 3.2 is incompatible with previous 3.0 releases, 3.2 and 3.0/3.1 are "equally incompatible" with whatever the systems are using now.