That doesn't look like a proof to me. It looks like you don't understand the definition (or spelling) of "embarrassingly parallel". Maybe you should ask Ken.
So you have a beautiful operating system which no one will use, but which you continue to loudly insist is superior. Great, I'm very happy for you. Please join the VMS, Amiga and BeOS trolls and play amongst yourselves.
nothing but gcc can compile the linux kernel anyway
So it's a bit silly to suggest using another compiler, isn't it? Personally I find/bin/true is even faster than Plan 9, when I don't care about the results.:-)
I don't think "embarrassingly parallel" means what you think it means, because compiling the kernel clearly is not such a problem. There are dependencies between tasks, only a limited number of tasks can be issued at a time and the whole thing ends up in two big links that can't be parallelized at all. In that benchmark, you end up with all but one CPU idle for the last second or so.
I agree, those four make a great toolkit. I will have to check out nc sometime.
If I already had my source on a fast NFS server, nc might be a good deal. In my experience development on NFS is noticeably slower than working with a checkout on a local disk, but I suppose it could be made faster.
I sympathise with you a lot, and I think a lot of the Gentoo stuff harpooned at funroll-loops is pretty silly.
However: small pauses are perceived as a computer that's clunky and hard to use; the difference between a 0.2s response to an action and a 1.0s lag is numerically small but psychologically enormous. It can make the system more fun, or less annoying, to use.
Now is rebuilding every package from source a good way to achieve this? Probably not. I think all the effort that goes into Gentoo would be better directed towards fixing the applications so that they just use less cycles. Improve the algorithm, don't fuck with the compiler. Of course many of the people working on Gentoo ports don't have the skills or experience to fix the core of the applications, but it would be nice if they at least tried.
To get back to the topic: when distcc reduces compile time, it stops me getting distracted while waiting for my program to build. The delay can cause either annoyance, or lost productivity (if I get distracted by slashdot). Again: numerically small, psychologically large.
If you're suffering this, it's easy to avoid by simply setting DISTCC_MMAP=0 DISTCC_SENDFILE=0. This avoids the kernel bug at a slight performance cost.
It's more likely that programmers will just use languages that waste machine time but save programmer time.
On the other hand the death of C or C++ has been predicted for about 20 years now, and it's still pretty popular. So I don't think large C packages will go out of style any time soon.
The promise of distcc is closely related to source distributions like Gentoo. The benefit is overstated.
The promise has nothing to do with Gentoo. distcc was released before Gentoo was well-known, and is useful to people who never run Gentoo.
You see, some of us actually develop our own software, rather than building distributions from source. If you write your own code in C or C++, you need to compile it, probably many times per day. If you work on large projects, getting builds done in seconds rather than minutes can make the whole development process more pleasant.
cpp is very cheap to run; you can go up to about 20 helper machines before the client runs out of CPU to run the preprocessor.
ld is more of a problem, because it can take a long time to run and is hard to parallelize. But for many programs there are only a few linker invocations right at the end, so doing them locally doesn't hurt too much.
Absolutely, I use it at home all the time. It's great for sofa computing: sit on the sofa with a modest laptop, and send your compile jobs across a wireless network to a faster machine in the study.
If you use the LZO compression option then it's quite useful even on 5Mbps wireless.
You can also tell distcc to run as many jobs remotely as possible to keep the laptop from scorching your lap.
It's really nice to be able to build the kernel from source in a reasonable time on a 800MHz machine.
nc requires the machines to have a shared filesystem mounted at the same point, synchronized clocks and exactly the same headers, libraries and tools installed. (Similarly for all the dozens of other times this idea has been invented: Sun dmake, pvmake, doozer, dbuild,....)
If you have that setup and you're sure everything will always be in sync, fine, you can distribute many jobs. Although distcc requires the compilers be the same, it is far more forgiving of all the variables. It may also be faster, depending on the setup: NFS is pretty awfully slow on modern machines.
The whole point of distcc is that you can install it without needing root privileges, without needing to use NFS, and without needing to reconfigure your machines.
Both of them are likely to break on buggy makefiles that can't handle -j. So fix your makefile, or, as you say, use SCons. SCons rocks, and rocks even harder with distcc.
Sheesh. You seem to be enormously confused about how inlining works. It is done by the compiler, not by the linker. If you don't believe me, try it for yourself:
static inline int a(void) {
return 0xdeadbeef; }
int main(void) {
return a(); }
Build this with "gcc -c -finline tryinline.c" and disassemble the object file. You will see the function has been inlined, although the linker was not run.
10: movl $0xdeadbeef,0xfffffffc(%ebp)
note that FILE is not available in a header, and any code outside the library that depends on the internal structure of FILE is broken. this includes your inlined function.
This is impossible. Try it yourself, and you'll see it doesn't work.
If ftell() is to be inlined, it must be defined in the public header, and the data type must be previously defined in the public header as well. Both of them are part of the public API. There is no way to have inline functions that depend on the internals of opaque data types. (Well, you can kind of fake hiding by using data types like FILE__impl_dont_touch, but it's still in the public header.)
(Some advanced compilers can do inter-file optimization and a kind of link-time inlining, but they don't do it for shared libraries, and it still doesn't behave the way you think it does.)
That's an example of a change that the libc maintainers should not make if they want to keep binary compatibility. If FILE is defined in the header, applications might use it an then they'll break when it changes. And in fact glibc seems to have FILE only as an opaque data type.
So it's a good idea to not publish data types that you expect will change, and to not publish for inlining any functions whose definitions might change. If you do need to change them, then you'll need a new library version. If you look in/usr/include you'll see they've pretty much stuck to those rules.
Anyhow, regardless of all this: when the compiler reads a header file it has no idea whether external functions declared there will eventually be resolved from a dynamic library, a shared library, or whatever. Even if the compiler authors wanted to do what you say, there would be no way to do it other than to disable inlines altogether.
If a header say a function should be considered for inlining, that's what the compiler is going to do. The onus is on the library author to write an interface that will be sufficiently stable in the future. It is not the compilers job to prevent you shooting yourself in this particular toe.
And in fact, the really cool bit is that gcc/glibc will detect when the argument is a constant and do it at compile time. So any protocol headers which have htonl(0xdeadbeef) will compile down to a constant 0xefbeadde on i386. Neat!
Let's look at the situation you describe. The inline function must be declared in the public header file for the application to see it. This header defines the API for the library.
Now you say that the library changed the API in an incompatible way. Is that going to break any apps built against the old version when they try to run against the new one? Yes, of course it is. The same thing would happen if you changed a type declaration or a function prototype or basically any other compatability point in the header. So, don't do that: if you have an interface that is meant to be binary-compatible, don't change it.
On the other hand, suppose you didn't actually make it incompatible, but just fixed a bug in the inlined function. Now you need to rebuild any applications that touch it. Yep, no getting around it, that is a cost of being inlined. If you don't want that, don't inline them. If you change an interface, you generally need to update or rebuild everyone who calls through it.
So the lesson is? The compiler cannot prevent you making mistakes. Don'dynamict assume this is a compiler bug, or you look even dumber. (Anyhow, how on earth do you expect the compiler was going to know whether an inline was also defined in a shared library? The question is meaningless at the level of a single source file.)
Rather than whining about the compiler, just stick to the simple rules: don't inline functions unless there is a good reason, and keep stable APIs stable.
I don't think they are repackaging print engines. They certainly started out repackaging (Canon?) print engines, with the software and controller done by HP. A few years ago they designed their own print engine too.
Certainly some computers are repackaged.
HP sell bulk A4 paper now. I can see the connection (ink jets, ink, inkjet paper, laser paper) but it does seem to show a lack of focus.
unless you're linking your libc statically, it can't be inline. it similarly can't be inline if you use a function pointer to it in some fashion.
Don't be silly. (Do the moderators actually think before scoring +1?) gcc is perfectly capable of inlining functions even when glibc is dynamically linked. It can also inline functions whose address is taken, just by generating a separate copy. Any other compiler clever enough to have inlines is very likely to do the same.
I put the facts before my certified tax advisor and he said it was OK, so that's good enough for me. In my case it was medically justified, although I only had verbal advice to that effect. I think an Aeron which I bought at AUD999 is small enough that it can be written off as an expense rather than depreciated as an asset, but I'm not sure.
The tax office doesn't care if you thought you were doing the right thing or not.
That is not quite true. Well-intentioned ignorance is not an excuse, but it can be a mitigating factor. Many of their penalties run as something like X for negligence/ignorance, 3X for wilful or gross negligence, 5X for criminal intent.
Anyhow, your basic point is right: don't make assumptions about tax without checking with a qualified professional first, or the tax office will ransack your junk even more gleefully than before.
Your salary sacrifice idea might be good, or it might introduce some fringe benefit tax liability. (Companies cannot just randomly give you things in lieu of salary.) Again, see an accountant first.
So: buy one, claim it as a work expense tax deduction (which cuts the price in half, in AU), and take it to the office. I did. Over three years so far I'm down to less per day than I spend on coffee, and it saves me from needing physio.
Are Apple really the quality leader? I don't deny that they make very attractive and cleverly designed products (as do BMW) but is the quality of manufacture really there?
My circle of friends have had a lot of reliability problems with Apple products. My girlfriend recently bought an iPod from an Apple dealer, and the screen on the first one she bought didn't work at all. She had to argue with them for five-ten minutes to get them to swap it immediately, rather than making her wait a couple of weeks to get a replacement from Apple HQ. (Great customer experience!)
My other friend had a TiBook, in which two drives failed in a matter of months, and then the motherboard failed. When he took it in to get the motherboard replaced, the apple monkeys said they could not move the hard drive across to the new machine, so he would lose all his data since his last backup, since the machine would no longer boot. They wouldn't let him remove the old drive himself either, since that would void the warranty. They thought this was entirely reasonable: maybe most of their users don't store any data they care about? This was their policy even though swapping a hard drive from one machine to another is something most nerdy twelve-year-olds could do without trouble. I think he ended up getting the new replacement machine, selling it, and getting an x86 laptop instead.
You hear similar stories about BMWs: beautiful design, but many little glitches and a large fraction of clueless dealers. I went to a BMW motorcycle shop a while ago and the salesdroid couldn't even ride, and didn't know the first thing about motorcycles. If I were a design engineer at Apple or BMW I'd feel really let down.
If I really wanted an Apple I wouldn't let this put me off -- and I do really appreciate the gorgeous whole-system design. I would just make regular backups to another (non-Apple) machine. So the situation is similar to what people say about BMW: great design, but (for the money) very unreliable quality and service. If I had the spare money I'd probably buy either a BMW or an Apple machine at least once in my life, but I'd go into it prepared to fight hard to get my warranty entitlements.
The nub of the problem is this: the two companies have built such strong brands that for many customers there is no substitute. If I'm buying a regular commodity SATA drive, I can look at price, quality reports, speed and so on and choose between many vendors. But if I have my heart set on an iPod or an M3 then I have to take it or leave it. The competitive pressure for quality is much less. Of course the downside is that when customers have such an emotional attachment they get really bitter when they're screwed around -- as did the two people mentioned.
Slashdot Mirror
That doesn't look like a proof to me. It looks like you don't understand the definition (or spelling) of "embarrassingly parallel". Maybe you should ask Ken.
So you have a beautiful operating system which no one will use, but which you continue to loudly insist is superior. Great, I'm very happy for you. Please join the VMS, Amiga and BeOS trolls and play amongst yourselves.
nothing but gcc can compile the linux kernel anyway
/bin/true is even faster than Plan 9, when I don't care about the results. :-)
So it's a bit silly to suggest using another compiler, isn't it? Personally I find
I don't think "embarrassingly parallel" means what you think it means, because compiling the kernel clearly is not such a problem. There are dependencies between tasks, only a limited number of tasks can be issued at a time and the whole thing ends up in two big links that can't be parallelized at all. In that benchmark, you end up with all but one CPU idle for the last second or so.
I agree, those four make a great toolkit. I will have to check out nc sometime.
If I already had my source on a fast NFS server, nc might be a good deal. In my experience development on NFS is noticeably slower than working with a checkout on a local disk, but I suppose it could be made faster.
I sympathise with you a lot, and I think a lot of the Gentoo stuff harpooned at funroll-loops is pretty silly.
However: small pauses are perceived as a computer that's clunky and hard to use; the difference between a 0.2s response to an action and a 1.0s lag is numerically small but psychologically enormous. It can make the system more fun, or less annoying, to use.
Now is rebuilding every package from source a good way to achieve this? Probably not. I think all the effort that goes into Gentoo would be better directed towards fixing the applications so that they just use less cycles. Improve the algorithm, don't fuck with the compiler. Of course many of the people working on Gentoo ports don't have the skills or experience to fix the core of the applications, but it would be nice if they at least tried.
To get back to the topic: when distcc reduces compile time, it stops me getting distracted while waiting for my program to build. The delay can cause either annoyance, or lost productivity (if I get distracted by slashdot). Again: numerically small, psychologically large.
If you're suffering this, it's easy to avoid by simply setting DISTCC_MMAP=0 DISTCC_SENDFILE=0. This avoids the kernel bug at a slight performance cost.
Of course the Plan 9 compiler couldn't actually build the Linux or BSD kernel, which is a slight drawback to your otherwise clever plan...
distcc gives you sub-minute builds, without needing to rewrite your whole kernel into a new C dialect. Sounds like a good deal to me.
Yes, it's a security problem. Someone on your network segment can fuck with your builds. Don't turn it on unless you trust your network.
It's more likely that programmers will just use languages that waste machine time but save programmer time.
On the other hand the death of C or C++ has been predicted for about 20 years now, and it's still pretty popular. So I don't think large C packages will go out of style any time soon.
Insightful, or Troll? The eternal question....
The promise of distcc is closely related to source distributions like Gentoo. The benefit is overstated.
The promise has nothing to do with Gentoo. distcc was released before Gentoo was well-known, and is useful to people who never run Gentoo.
You see, some of us actually develop our own software, rather than building distributions from source. If you write your own code in C or C++, you need to compile it, probably many times per day. If you work on large projects, getting builds done in seconds rather than minutes can make the whole development process more pleasant.
cpp is very cheap to run; you can go up to about 20 helper machines before the client runs out of CPU to run the preprocessor.
ld is more of a problem, because it can take a long time to run and is hard to parallelize. But for many programs there are only a few linker invocations right at the end, so doing them locally doesn't hurt too much.
Absolutely, I use it at home all the time. It's great for sofa computing: sit on the sofa with a modest laptop, and send your compile jobs across a wireless network to a faster machine in the study.
If you use the LZO compression option then it's quite useful even on 5Mbps wireless.
You can also tell distcc to run as many jobs remotely as possible to keep the laptop from scorching your lap.
It's really nice to be able to build the kernel from source in a reasonable time on a 800MHz machine.
See the distcc FAQ:
....)
nc requires the machines to have a shared filesystem mounted at the same point, synchronized clocks and exactly the same headers, libraries and tools installed. (Similarly for all the dozens of other times this idea has been invented: Sun dmake, pvmake, doozer, dbuild,
If you have that setup and you're sure everything will always be in sync, fine, you can distribute many jobs. Although distcc requires the compilers be the same, it is far more forgiving of all the variables. It may also be faster, depending on the setup: NFS is pretty awfully slow on modern machines.
The whole point of distcc is that you can install it without needing root privileges, without needing to use NFS, and without needing to reconfigure your machines.
Both of them are likely to break on buggy makefiles that can't handle -j. So fix your makefile, or, as you say, use SCons. SCons rocks,
and rocks even harder with distcc.
Got any photos?
Sheesh. You seem to be enormously confused about how inlining works. It is done by the compiler, not by the linker. If you don't believe me, try it for yourself:
static inline int a(void) {
return 0xdeadbeef;
}
int main(void) {
return a();
}
Build this with "gcc -c -finline tryinline.c" and disassemble the object file. You will see the function has been inlined, although the linker was not run.
10: movl $0xdeadbeef,0xfffffffc(%ebp)
note that FILE is not available in a header, and any code outside the library that depends on the internal structure of FILE is broken. this includes your inlined function.
This is impossible. Try it yourself, and you'll see it doesn't work.
If ftell() is to be inlined, it must be defined in the public header, and the data type must be previously defined in the public header as well. Both of them are part of the public API. There is no way to have inline functions that depend on the internals of opaque data types. (Well, you can kind of fake hiding by using data types like FILE__impl_dont_touch, but it's still in the public header.)
(Some advanced compilers can do inter-file optimization and a kind of link-time inlining, but they don't do it for shared libraries, and it still doesn't behave the way you think it does.)
That's an example of a change that the libc maintainers should not make if they want to keep binary compatibility. If FILE is defined in the header, applications might use it an then they'll break when it changes. And in fact glibc seems to have FILE only as an opaque data type.
/usr/include you'll see they've pretty much stuck to those rules.
So it's a good idea to not publish data types that you expect will change, and to not publish for inlining any functions whose definitions might change. If you do need to change them, then you'll need a new library version. If you look in
Anyhow, regardless of all this: when the compiler reads a header file it has no idea whether external functions declared there will eventually be resolved from a dynamic library, a shared library, or whatever. Even if the compiler authors wanted to do what you say, there would be no way to do it other than to disable inlines altogether.
If a header say a function should be considered for inlining, that's what the compiler is going to do. The onus is on the library author to write an interface that will be sufficiently stable in the future. It is not the compilers job to prevent you shooting yourself in this particular toe.
And in fact, the really cool bit is that gcc/glibc will detect when the argument is a constant and do it at compile time. So any protocol headers which have htonl(0xdeadbeef) will compile down to a constant 0xefbeadde on i386. Neat!
Uh,
Sorry if that was a bit flamey. I've just had a few too many cases recently of people saying "it's a compiler bug!" when they just don't understand.
Let's look at the situation you describe. The inline function must be declared in the public header file for the application to see it. This header defines the API for the library.
Now you say that the library changed the API in an incompatible way. Is that going to break any apps built against the old version when they try to run against the new one? Yes, of course it is. The same thing would happen if you changed a type declaration or a function prototype or basically any other compatability point in the header. So, don't do that: if you have an interface that is meant to be binary-compatible, don't change it.
On the other hand, suppose you didn't actually make it incompatible, but just fixed a bug in the inlined function. Now you need to rebuild any applications that touch it. Yep, no getting around it, that is a cost of being inlined. If you don't want that, don't inline them. If you change an interface, you generally need to update or rebuild everyone who calls through it.
So the lesson is? The compiler cannot prevent you making mistakes. Don'dynamict assume this is a compiler bug, or you look even dumber. (Anyhow, how on earth do you expect the compiler was going to know whether an inline was also defined in a shared library? The question is meaningless at the level of a single source file.)
Rather than whining about the compiler, just stick to the simple rules: don't inline functions unless there is a good reason, and keep stable APIs stable.
I don't think they are repackaging print engines. They certainly started out repackaging (Canon?) print engines, with the software and controller done by HP. A few years ago they designed their own print engine too.
Certainly some computers are repackaged.
HP sell bulk A4 paper now. I can see the connection (ink jets, ink, inkjet paper, laser paper) but it does seem to show a lack of focus.
Wow, a boss who literally gives their sysadmins chainsaws and woodchippers. I don't know if I'm scared or impressed. ;-)
unless you're linking your libc statically, it can't be inline. it similarly can't be inline if you use a function pointer to it in some fashion.
Don't be silly. (Do the moderators actually think before scoring +1?) gcc is perfectly capable of inlining functions even when glibc is dynamically linked. It can also inline functions whose address is taken, just by generating a separate copy. Any other compiler clever enough to have inlines is very likely to do the same.
I put the facts before my certified tax advisor and he said it was OK, so that's good enough for me. In my case it was medically justified, although I only had verbal advice to that effect. I think an Aeron which I bought at AUD999 is small enough that it can be written off as an expense rather than depreciated as an asset, but I'm not sure.
The tax office doesn't care if you thought you were doing the right thing or not.
That is not quite true. Well-intentioned ignorance is not an excuse, but it can be a mitigating factor. Many of their penalties run as something like X for negligence/ignorance, 3X for wilful or gross negligence, 5X for criminal intent.
Anyhow, your basic point is right: don't make assumptions about tax without checking with a qualified professional first, or the tax office will ransack your junk even more gleefully than before.
Your salary sacrifice idea might be good, or it might introduce some fringe benefit tax liability. (Companies cannot just randomly give you things in lieu of salary.) Again, see an accountant first.
So: buy one, claim it as a work expense tax deduction (which cuts the price in half, in AU), and take it to the office. I did. Over three years so far I'm down to less per day than I spend on coffee, and it saves me from needing physio.
I'll take it if you don't want it. :-)
Are Apple really the quality leader? I don't deny that they make very attractive and cleverly designed products (as do BMW) but is the quality of manufacture really there?
My circle of friends have had a lot of reliability problems with Apple products. My girlfriend recently bought an iPod from an Apple dealer, and the screen on the first one she bought didn't work at all. She had to argue with them for five-ten minutes to get them to swap it immediately, rather than making her wait a couple of weeks to get a replacement from Apple HQ. (Great customer experience!)
My other friend had a TiBook, in which two drives failed in a matter of months, and then the motherboard failed. When he took it in to get the motherboard replaced, the apple monkeys said they could not move the hard drive across to the new machine, so he would lose all his data since his last backup, since the machine would no longer boot. They wouldn't let him remove the old drive himself either, since that would void the warranty. They thought this was entirely reasonable: maybe most of their users don't store any data they care about? This was their policy even though swapping a hard drive from one machine to another is something most nerdy twelve-year-olds could do without trouble. I think he ended up getting the new replacement machine, selling it, and getting an x86 laptop instead.
You hear similar stories about BMWs: beautiful design, but many little glitches and a large fraction of clueless dealers. I went to a BMW motorcycle shop a while ago and the salesdroid couldn't even ride, and didn't know the first thing about motorcycles. If I were a design engineer at Apple or BMW I'd feel really let down.
If I really wanted an Apple I wouldn't let this put me off -- and I do really appreciate the gorgeous whole-system design. I would just make regular backups to another (non-Apple) machine. So the situation is similar to what people say about BMW: great design, but (for the money) very unreliable quality and service. If I had the spare money I'd probably buy either a BMW or an Apple machine at least once in my life, but I'd go into it prepared to fight hard to get my warranty entitlements.
The nub of the problem is this: the two companies have built such strong brands that for many customers there is no substitute. If I'm buying a regular commodity SATA drive, I can look at price, quality reports, speed and so on and choose between many vendors. But if I have my heart set on an iPod or an M3 then I have to take it or leave it. The competitive pressure for quality is much less. Of course the downside is that when customers have such an emotional attachment they get really bitter when they're screwed around -- as did the two people mentioned.