We've fixed that for 3.4, and for 3.3 to some
on
GCC 3.3 Released
·
· Score: 4, Insightful
"...to some extent." Why give a Subject: line textbox that won't let me use all of it? Grrr.
Anyhow. One of the big speed hits for iostream code was the formatting routines. Some other reply has a subject like "if you're using fstream you're not interested in performance anyhow," which is so wrongheaded I won't even bother to read it. There's no reason why iostreams code shouldn't be faster than the equivalent stdio code: the choice of formatting operations is done at compile-time for iostreams, but stdio has to parse the little "%-whatever" formatting specs at runtime.
However, many iostreams libraries are implemented as small layers on top of stdio for portability and compatability, which means that particular implementation will always be slower.
We were doing something similar until recently. Not a complete layer on top of stdio, but some of the formatting routines were being used for correctness' sake. We all knew it sucked, but none of the 6 maintainers had time to do anything about it, and the rest of the world (that includes y'all,/.) was content to bitch about it rather than submit patches. Finally, Jerry Quinn started a series of rewrites and replacements of that section of code, aimed at bringing performance back to 2.x levels. One of the newer maintainers, Paolo Carlini, has been working unceasingly at iostream and string performance since.
So, all of that will be in 3.4. Chunks of it are also in 3.3, but not all. (I don't recall exactly how much.)
I think that the gcc group had that figured out first.
No we didn't. It's an old idea.
gcc uses front ends to translate the c, c++, fortran, java, and whatever other languages it can use to intermediate files, which are then compiled to assembly then machine code.
I don't recall what the 1.x series did, but the 2.x series (first release early 1992) never compiled to intermediate languages.
The 3.x series certainly doesn't. Everything goes straight from the front-end language (C++, Java, whatever) to assembly. Many compilers build to an intermediate language, e.g., C, and then simply compile that -- in fact, the very first C++ compilers from Bell Labs did this -- but GCC is not one of them.
Now, if you're talking about an intermediate in-memory representation, sure, every compiler does that, starting with the simple "syntax tree" that we all learned in CS 101. But don't call them files, since they're never written out and (often) don't even have a convenient text representation.
it sounds like hard drives may be nothing but backups before long.
This is one of the integral design choices in Plan 9. RAM is considered nothing more than a cache for the hard drives, and the hard drives are considered nothing more than a cache for the gigantic WORM drive backups (which happen nightly, and are made available as part of the normal "filesystem".
...something like the useful tool in the early scenes of Niven's The Gripping Hand. Quoting from memory:
[Bury calls Dr. Buckman at the university, using a voice-activated computer, no screen; its call sign is Horvendile]
"This is Dr. Buckman's auxiliary brain. Dr. Buckman is asleep at present. Mr. Bury, he thanks you for the gift that you sent him. Is there sufficient urgency to wake him?"
"No. I would like to meet with him when convenient. We are in [name of city]."
"Dr. Buckman should have free time on Wednesday."
"Excellent. Arrange a time with my house computer."
"Would you like to leave a message?"
"Yes. Jacob, I told your machine Wednesday, but any time will do. I'd like to see you before one of us dies of old age and sloppy medical techniques. Message ends."
[slight pause, Bury continues]
"Horvendile."
"Sir."
"Appointment with Dr. Jacob Buckman, highest social priority."
"Sir. His computer confirms [some date and time]."
That's a personal server. Until I can do that, don't pester me.
No, I don't remember who sent it to me. And I'm turning off the webserver in half an hour so I can go back to getting real work done, so somebody mirror the damn thing and stop hammering my home DSL.:-)
I wish I could find this webpage again. (Google's not responding and I'm too busy to wait.) Anyhow, some guy had a great quote which IMHO accurately summed things up as far as free operating systems go. Went something like (in random order)
FreeBSD is the most powerful OS.
NetBSD is the most portable OS.
OpenBSD is the most secure OS.
Linux is the most popular OS.
I agree, this wouldn't be easier if the user was working with a single version. But it might be easier than downloading all of those versions of the JDK, if the user wants to try each one.
Offering compilation over the web has been around for a while. I don't know why this is news.
I know that poster well, by the sound of it. It's hanging on the wall in my mentor's office.
It's an army of BSD-family on one side, an army of SystemV-family on the other side, and in the middle (not far from the wizard(s)), trampled underfoot, pierced with many blades, completely overlooked, dressed in innocent white, is the user.
It's a reminder of what to avoid, not an advertisement. But perhaps you knew that and didn't say in your post.
(The poster is also chock full of *nix references: there's a cat walking around, some of the soldiers are armed with pipes, etc, etc.)
After Richard Feynman was asked to investigate the Challenger accident, he wrote up his experiences. They're published as the second half of his second autobiography.
He was stupified by the amount of fudge-factoring that went on at NASA. The MTBF for a component would be listed at 300 flight hours, and when he asked how they arrived at such a nice round figure, managers would retroactively come up with a listing where each sub-component had MTBFs listed to decimal places, 34.8712 hours, 29.1109 hours,... and they all conveniently added up to exactly 300 hours.
Engineers were going nuts, but managers kept overriding the decisions. It was a fantastic "it looks nice on paper, therefore it works this way in real life, and fuck the laws of physics" mindset.
I just re-read both of the IT books back-to-back, and was imagining how they might be done as a movie. And I came to a similar conclusion; the American moviegoing audience is just too stupid to understand something like tidal effects and gravity gradients. Plus minor plot details such as "day" and "year" not meaning what you originally think they mean.
I also feel that the "surprise" involving who actually mutinied would not be able to be put off until the second book. (Niven planned both books at the same time; the first book sets up the surprise, although you can figure it out without too much trouble with his clues, and the second one reveals it.) Since large plot points in the second book revolve around the timing of the revealing of the "surprise," moving it would largely obviate the whole second book.
It works anywhere, with a few exceptions. All you need is a drop of typical blood. But it's typically very difficult to pierce the skin as easily and and with minimal damage (so to speak) as it is on the fingertips.
The early typewriters -- the kind with a ribbon of ink over a piece of paper, and each keypress would swing a thin metal bar down to smack the ribbon -- would jam easily if multiple keys were hit within a brief time. (The bars would cross.)
So the keys were somewhat scattered, in order to slow typing speed down to where the bars couldn't possibly interfere with one another, because the human couldn't hit them that quickly. E.g., major vowels on the outside of the board. (There's also an old joke about all the letters needed to spell "typewriter" being placed on the top row so that the traveling typewriter salesmen could find them, and type "typewriter" during a demo. See? Even early 20th century geeks made stupid-marketer jokes.)
Anyhow, the point: QWERTY is not the end-all be-all of interface design. Look at Dvorak. The/reason/ for the QWERTY design is long gone, there's nothing holding us back except reluctence to change.
(That said, I'll stick with my QWERTY split keyboard, thanks.)
And it doesn't hurt. There's no pain involved in testing your blood sugar, other than the fact that it's a pain in the ass to have to do it all the time.
It hurts like a sonuvabitch.
Actually, it's not the pinprick that hurts. It's the little scabs/scars on the fingertips that kill me later, when I'm typing. (Yet another bonus to being diabetic: minor flesh wounds take longer to heal.) As I code and sysadmin[*] for a living, little flashes of pain with every keystroke are a major downside.
As soon as the hold-a-laser-sensor-to-your-skin glucose meters drop within my price range, I'm there. The contact lenses would be cool too ("he's unconscious and his eyes are turning purple, what the fuck does that mean?"), but I've never liked wearing contacts.
[*] Please don't tell my mother I'm a sysadmin; she thinks I play piano in a whorehouse.
I heard there is an editor called Mutt editor...?
Both programs sound similar but have no connection whatsoever. Additionally, both authors know of the other project and have no problems with the name similarity.
The "problem domains" here are very different: one is a browser, the other is a database. With careful communication (the hallmark of a good computer scientist) there would be no problem. Pity that Aunt Maggie would tend to confuse them.
Nah, I was just in a bad mood. Nothing personal. (I'm more civil in email than I am on/., and less civil in chat rooms than I am on/. Odd kind of spectrum.)
What irritates me (and other maintainers) is not the observations that you and others make, it's the insidious suggestions and inferences. If you don't know why a policy is in place, fer pity's sake just ASK.
I have to wonder what takes the place of the liver. (Articles have been/.ed into dust.)
Given the choice between a normal liver plus insulin injections, versus a "virtual pancreas" and some unknown liver treatment, I think I'd stick with the devil I knew.
More precisely, I know how my body reacts to insulin injections. Nobody knows how it would react to - ah screw it, I can't seem to express this thought coherently.
To contribute to GCC, in fact, it is not enough that you GPL your code and give a license to the GNU Project. No, you have to ASSIGN COPYRIGHT of the code to GNU, basically saying that the code is no longer yours,
...it is my sad duty to inform you that you have your head stuck up your ass.
The requirement of copyright assignment for non-trivial contributions is for the coder's protection, not the FSF's. Pretend this requirement didn't exist, and you contribute some hefty cool optimization. The copyright is in your name. Now MegaEvilCorp steals it.
It's under the GPL, so in theory you can fight it. But what resources do you have? You're barely making shit per hour at the local Best Buy and you're saving up for a new car. Nobody else has the legal right to step in to challenge MegaEvilCorp, because only you own the copyright.
Or perhaps you're a programmer for NotTooBadCorp, who promised you that your work for GCC wouldn't be considered a conflict of interest with your job duties. (After all, you program widgets in your job, not compilers.) But then the hefty cool optimization stirs up attention, and the CEO decides that maybe NotTooBadCorp officially owns you, your apartment, your kidneys, and all the code you contributed to GCC. What are you going to do about it?
Other scenarios are possible. In all of them, you get screwed, and so do all GCC users.
But since the FSF has the copyright, they can enforce the GPL should that become necessary. They can afford it.
Also, you probably don't realize that contributors are supposed to keep track of what they contribute. That way we can, with a written notice, revoke the copyright assignment. The FSF gives you the ownership back, and you have to take your code out of the source. So it's not like the assignment is etched in stone; the code you wrote is still yours.
The DoD funded the Arpanet because big honking computers were expensive. It just wasn't worth the money to buy one for your group when another group a few hundred miles away already had a computer that would do the job. All that needed to happen was to hook them up.
Defense had nothing to do with it. "Surviving a nuclear attack" had nothing to do with it. Getting the most computer power from a limited and geographically-widespread number of computers had everything to do with it.
IIRC, the fact that it was actually a.mil wasn't mentioned. The link itself was hidden (they used HTML email).
What I do remember clearly was that the training emphasizes that username/password should only be given out when you expect in advance to give it out (e.g., logging into your desktop) or are told by confirmed authority well in advance (e.g., "next week you will need to do blah blah blah, this will require your password. yours truly, signed by SSL/PKI, Brigadier General God"). Unexpected requests for passwords should be treated as suspicious.
It's supposed to be a paranoia-inducing test. We get network breakin attempts (and I mean this literally) constantly.
Slashdot Mirror
"...to some extent." Why give a Subject: line textbox that won't let me use all of it? Grrr.
Anyhow. One of the big speed hits for iostream code was the formatting routines. Some other reply has a subject like "if you're using fstream you're not interested in performance anyhow," which is so wrongheaded I won't even bother to read it. There's no reason why iostreams code shouldn't be faster than the equivalent stdio code: the choice of formatting operations is done at compile-time for iostreams, but stdio has to parse the little "%-whatever" formatting specs at runtime.
However, many iostreams libraries are implemented as small layers on top of stdio for portability and compatability, which means that particular implementation will always be slower.
We were doing something similar until recently. Not a complete layer on top of stdio, but some of the formatting routines were being used for correctness' sake. We all knew it sucked, but none of the 6 maintainers had time to do anything about it, and the rest of the world (that includes y'all, /.) was content to bitch about it rather than submit patches. Finally, Jerry Quinn started a series of rewrites and replacements of that section of code, aimed at bringing performance back to 2.x levels. One of the newer maintainers, Paolo Carlini, has been working unceasingly at iostream and string performance since.
So, all of that will be in 3.4. Chunks of it are also in 3.3, but not all. (I don't recall exactly how much.)
No we didn't. It's an old idea.
I don't recall what the 1.x series did, but the 2.x series (first release early 1992) never compiled to intermediate languages.
The 3.x series certainly doesn't. Everything goes straight from the front-end language (C++, Java, whatever) to assembly. Many compilers build to an intermediate language, e.g., C, and then simply compile that -- in fact, the very first C++ compilers from Bell Labs did this -- but GCC is not one of them.
Now, if you're talking about an intermediate in-memory representation, sure, every compiler does that, starting with the simple "syntax tree" that we all learned in CS 101. But don't call them files, since they're never written out and (often) don't even have a convenient text representation.
Speaking of Lucent/Bell Labs...
This is one of the integral design choices in Plan 9. RAM is considered nothing more than a cache for the hard drives, and the hard drives are considered nothing more than a cache for the gigantic WORM drive backups (which happen nightly, and are made available as part of the normal "filesystem".
I'd hate to be this guy.
...something like the useful tool in the early scenes of Niven's The Gripping Hand. Quoting from memory:
That's a personal server. Until I can do that, don't pester me.
Isn't this tired myth dead yet?
Fuck, I just debunked it less than two weeks ago. Guess you're one of the millions who don't browse at +3. :-)
It was all about research. Not necessarily acedemic, but research.
but here you go:
Microsoft's latest wall poster
No, I don't remember who sent it to me. And I'm turning off the webserver in half an hour so I can go back to getting real work done, so somebody mirror the damn thing and stop hammering my home DSL. :-)
Which part of as far as free operating systems go did you skip over?
I wish I could find this webpage again. (Google's not responding and I'm too busy to wait.) Anyhow, some guy had a great quote which IMHO accurately summed things up as far as free operating systems go. Went something like (in random order)
I agree, this wouldn't be easier if the user was working with a single version. But it might be easier than downloading all of those versions of the JDK, if the user wants to try each one.
Offering compilation over the web has been around for a while. I don't know why this is news.
I know that poster well, by the sound of it. It's hanging on the wall in my mentor's office.
It's an army of BSD-family on one side, an army of SystemV-family on the other side, and in the middle (not far from the wizard(s)), trampled underfoot, pierced with many blades, completely overlooked, dressed in innocent white, is the user.
It's a reminder of what to avoid, not an advertisement. But perhaps you knew that and didn't say in your post.
(The poster is also chock full of *nix references: there's a cat walking around, some of the soldiers are armed with pipes, etc, etc.)
Predates Linux by quite a bit.
...pulled out of the management's ass.
After Richard Feynman was asked to investigate the Challenger accident, he wrote up his experiences. They're published as the second half of his second autobiography.
He was stupified by the amount of fudge-factoring that went on at NASA. The MTBF for a component would be listed at 300 flight hours, and when he asked how they arrived at such a nice round figure, managers would retroactively come up with a listing where each sub-component had MTBFs listed to decimal places, 34.8712 hours, 29.1109 hours, ... and they all conveniently added up to exactly 300 hours.
Engineers were going nuts, but managers kept overriding the decisions. It was a fantastic "it looks nice on paper, therefore it works this way in real life, and fuck the laws of physics" mindset.
I just re-read both of the IT books back-to-back, and was imagining how they might be done as a movie. And I came to a similar conclusion; the American moviegoing audience is just too stupid to understand something like tidal effects and gravity gradients. Plus minor plot details such as "day" and "year" not meaning what you originally think they mean.
I also feel that the "surprise" involving who actually mutinied would not be able to be put off until the second book. (Niven planned both books at the same time; the first book sets up the surprise, although you can figure it out without too much trouble with his clues, and the second one reveals it.) Since large plot points in the second book revolve around the timing of the revealing of the "surprise," moving it would largely obviate the whole second book.
It works anywhere, with a few exceptions. All you need is a drop of typical blood. But it's typically very difficult to pierce the skin as easily and and with minimal damage (so to speak) as it is on the fingertips.
The early typewriters -- the kind with a ribbon of ink over a piece of paper, and each keypress would swing a thin metal bar down to smack the ribbon -- would jam easily if multiple keys were hit within a brief time. (The bars would cross.)
So the keys were somewhat scattered, in order to slow typing speed down to where the bars couldn't possibly interfere with one another, because the human couldn't hit them that quickly. E.g., major vowels on the outside of the board. (There's also an old joke about all the letters needed to spell "typewriter" being placed on the top row so that the traveling typewriter salesmen could find them, and type "typewriter" during a demo. See? Even early 20th century geeks made stupid-marketer jokes.)
Anyhow, the point: QWERTY is not the end-all be-all of interface design. Look at Dvorak. The /reason/ for the QWERTY design is long gone, there's nothing holding us back except reluctence to change.
(That said, I'll stick with my QWERTY split keyboard, thanks.)
It hurts like a sonuvabitch.
Actually, it's not the pinprick that hurts. It's the little scabs/scars on the fingertips that kill me later, when I'm typing. (Yet another bonus to being diabetic: minor flesh wounds take longer to heal.) As I code and sysadmin[*] for a living, little flashes of pain with every keystroke are a major downside.
As soon as the hold-a-laser-sensor-to-your-skin glucose meters drop within my price range, I'm there. The contact lenses would be cool too ("he's unconscious and his eyes are turning purple, what the fuck does that mean?"), but I've never liked wearing contacts.
[*] Please don't tell my mother I'm a sysadmin; she thinks I play piano in a whorehouse.
If only more people could be this mature.
The "problem domains" here are very different: one is a browser, the other is a database. With careful communication (the hallmark of a good computer scientist) there would be no problem. Pity that Aunt Maggie would tend to confuse them.
Now that was funny. If I could use mod points I'd give 'em to you.
Nah, I was just in a bad mood. Nothing personal. (I'm more civil in email than I am on
What irritates me (and other maintainers) is not the observations that you and others make, it's the insidious suggestions and inferences. If you don't know why a policy is in place, fer pity's sake just ASK.
At least two other people understood me. The thought worked in the first paragraphs. Brain only gave out in that last one.
(Why am I even bothering to talk to an AC? Fuck, I must be bored.)
So, I can exchange taking insulin for the rest of my life with taking anti-rejection drugs for the rest of my life? What have I gained?
Clearly I'm missing a point somewhere.
I have to wonder what takes the place of the liver. (Articles have been
Given the choice between a normal liver plus insulin injections, versus a "virtual pancreas" and some unknown liver treatment, I think I'd stick with the devil I knew.
More precisely, I know how my body reacts to insulin injections. Nobody knows how it would react to - ah screw it, I can't seem to express this thought coherently.
...it is my sad duty to inform you that you have your head stuck up your ass.
The requirement of copyright assignment for non-trivial contributions is for the coder's protection, not the FSF's. Pretend this requirement didn't exist, and you contribute some hefty cool optimization. The copyright is in your name. Now MegaEvilCorp steals it.
It's under the GPL, so in theory you can fight it. But what resources do you have? You're barely making shit per hour at the local Best Buy and you're saving up for a new car. Nobody else has the legal right to step in to challenge MegaEvilCorp, because only you own the copyright.
Or perhaps you're a programmer for NotTooBadCorp, who promised you that your work for GCC wouldn't be considered a conflict of interest with your job duties. (After all, you program widgets in your job, not compilers.) But then the hefty cool optimization stirs up attention, and the CEO decides that maybe NotTooBadCorp officially owns you, your apartment, your kidneys, and all the code you contributed to GCC. What are you going to do about it?
Other scenarios are possible. In all of them, you get screwed, and so do all GCC users.
But since the FSF has the copyright, they can enforce the GPL should that become necessary. They can afford it.
Also, you probably don't realize that contributors are supposed to keep track of what they contribute. That way we can, with a written notice, revoke the copyright assignment. The FSF gives you the ownership back, and you have to take your code out of the source. So it's not like the assignment is etched in stone; the code you wrote is still yours.
The DoD funded the Arpanet because big honking computers were expensive. It just wasn't worth the money to buy one for your group when another group a few hundred miles away already had a computer that would do the job. All that needed to happen was to hook them up.
Defense had nothing to do with it. "Surviving a nuclear attack" had nothing to do with it. Getting the most computer power from a limited and geographically-widespread number of computers had everything to do with it.
IIRC, the fact that it was actually a
What I do remember clearly was that the training emphasizes that username/password should only be given out when you expect in advance to give it out (e.g., logging into your desktop) or are told by confirmed authority well in advance (e.g., "next week you will need to do blah blah blah, this will require your password. yours truly, signed by SSL/PKI, Brigadier General God"). Unexpected requests for passwords should be treated as suspicious.
It's supposed to be a paranoia-inducing test. We get network breakin attempts (and I mean this literally) constantly.