Your definition of "freedom" is self serving and wrong.
First, I didn't define "freedom". Secondly, what makes you think it's "self-serving"? You don't know a damn thing about me.
Re:How many licenses can fit on the head of a pin?
on
PHP Not Moving To The GPL
·
· Score: 2, Insightful
It's MORE FREE than GPL. It's more like a BSD license.
AAARGH! Once again, two usages of the word "free" are being completely confused.
The GPL is free as in free speech, meaning "freedom". With freedom, as we all know, comes responsibility.
PHP/MIT/BSD et al licences are free as in free time, meaning "no (or few) strings attached".
The PHP licence is only "more free" than the GPL if you use a different meaning of "free" than that which the GPL is based on. Making statements like this just confuses people even further, so please don't do it.
Having said that, the main complaints are that a) this is yet another licence, and b) it's not compatible with the GPL. The GPL is the most common free/open source software licence around, so coming up with a new incompatible licence for your software is a barrier to your software being adopted. If you're prepared to live with that, it's fine by me. I, in turn, will feel free to consider this a deciding factor should I choose to go elsewhere.
There is no "the" preferred code. Your code may be better on some platforms, but on others it may not be.
However, you do raise a good point. A coalescing register allocator, particularly one that was sensitive to target paths, could easily optimise the temporary version to:
w = x + y; w = w + z;
It's one fewer temporaries, but the same number of operations.
I haven't worked with GLSL et al, though I have done a lot of work with RenderMan shading language compilers, including writing two of them from scratch. I definitely agree that these shading languages are much easier to compiler compared with C++ or C. (The lack of user-defined types and recursion helps a LOT --- no fancy stack frames.) Similarly, the target platforms (usually some kind of virtual machine in the case of RenderMan) are invariably quite simple.
However, the problem is that even though the target platforms are simple, they're all extremely different. Most of them are SIMD architectures, but some are not. Some use stacks and others use register transfer. One or two (most notably Pixar's PRMan) execute annotated abstract syntax trees (called "shade trees") directly. Many compile to C++, but even then, they often have very different capabilities and limitations.
Take, for example, the following piece of code, where all of the variables are "varying" (that is, they vary over the grid being shaded):
w = x + y + z;
If the target machine supports SIMD addition, then it pays to use it. So we might use a temporary, and generate code like this, scheduling the two additions separately:
varying t = x + y; w = t + z;
If, however, you're compiling to C/C++, then you're better off scheduling the additions together:
for (all grid elements g) { g->w = g->x + g->y + g->z; }
This increases the effective size of each basic block and hence gives the C/C++ compiler a better chance of performing low-level optimisations.
And this is just showing the difference between two software VMs. I can only imagine what the differences are between the capabilities between two generations of NVIDIA hardware, let alone between NVIDIA and ATI. Leaving optimisation up to the IHV was definitely the right thing to do.
Actually, you could page out the ROM if you knew what you were doing.
The C64 had two ROMs: One for the kernel and one for the BASIC interpreter. It was common practice to "turn off" the interpreter ROM to give you more RAM if you were programming in assembler. It was slightly less common practice to do the same with the kernel, giving you "raw iron".
Oh, and I believe the ROMs were 8kb each, but my memory is a little fuzzy on that point.
POVRay is one of the best rendering systems out there, free or not.)
There are two main problems with it. First, its input format is completely incompatible with just about everything useful. This, admittedly, isn't POVRay's fault. It was written by people who didn't know better at a time when decent tools weren't generally available.
That said, it's a fairly moot point, because you could probably have written 500 Perl programs in the time it takes to optimize that one C prog.
Or you could have added 20 extra features and squashed 10 bugs in the Perl program, any one of which would have required rewriting large slabs of the C program in order to maintain the same performance.
Higher-level languages tend to be able to maintain performance (whether that performance is good or bad) in the face of maintenance, where a C or assembly program cannot.
That's a very good point. He may have had only one year of C (which explains why his C programming style wasn't that good at the time), but he'd effectively had years of system programming experience, just not commercial experience.
Coincidently in a recent interview, Linus decided he was not the inventor of Linux commenting in a ZDNet story, "I'd agree that 'inventor' is not necessarily the right word...(9)"
I love that quote too. If you had asked Brunel if he was the "inventor" of the Great Eastern, or asked John and Washington Roebling if they were the "inventors" of the Brooklyn Bridge, they would have said "no".
Great works of engineering are rarely "inventions" in the USPTO sense of the word.
I think that's true. As Ken Brown pointed out, Linus had only a year or so of C experience at the time. As Linus has pointed out, a lot of that code embarrasses him today.
The Harvard Business Review article did not claim that IT was unimportant. The main gist was that IT is not a strategic advantage to the typical business, though it once was. The reason is that everyone has it these days. It's no more a strategic advantage to your business than electricity is.
The author then argued that because everyone has it and everyone needs it, and it's not a strategic advantage, it follows that is a risk. Because it's something you have to have, and it's not a strategic advantage, it follows that the biggest concern is not having enough, but rather keeping an eye on costs. He questioned, for example, the wisdom of putting the IT guy (the confusingly-named "CIO") on the board of directors.
While I'm not defending the original article, the business environment in which it arose has given rise to two main things in US business, both of which are designed to try to minimise business risk in IT: Outsourcing, and open source.
Re:Do you realize just how many gigabytes of...
on
Rendering Shrek@Home?
·
· Score: 1
It's usually more gigabytes than terabytes. One estimate for Monsters, Inc was that a typical frame used 2Gb of gzipped geometry and 10Gb of texture data. You do get into the terabyte range when you start dealing with digitised photographic plates, but this is Shrek@Home, not LOTR@Home.
I was also extremely impressed by Spirit. However, the most impressive, IMO, was South Park.
Bear with me, there is method in my madness.
When I said "South Park", you probably said "oh, yeah, that was computer graphics, wasn't it; I forgot about that". The illusion was so good that it looked like real cartridge paper cutouts. Remember this next time you utter the word "photorealism".
Now I haven't been able to get to this article, so I'm going to guess here, but I assume, since Dreamworks does NOT use Pixar's Renderman, they have developed, or are using some other program that conforms to the Renderman Spec.
Wrong, though their renderers do solve the same kinds of problems that RenderMan-compliant renderers are supposed to solve.
For example, their shading system is based more closely on shade trees, but with very complex nodes written in C, more like Maya's hypergraph rather than Renderman SL.
Re:Why Final Fantasy failed.
on
Shrek 2 How-To
·
· Score: 1
Final Fantasy failed because brilliant visuals can't cover up a crap script.
1. If they released it, they'd have to support it, and they don't want to do that.
2. PDI are actually a very good citizen in the computer graphics community, unlike some companies we won't mention. They are very open about what technology they use, and they hold no (as far as I know) software patents.
Microkernels might have slightly lower throughput than monolithic macrokernels [...]
"Throughput", defined as the amount of work that the system can do just prior to being overloaded, is not the quantity that everyone wants to optimise for. Performance when you are overloaded, or latency when you're not, can be more important in some systems (such as yours).
Just thought I'd mention this, because not a lot of people understand what "throughput" is, and even fewer can tell when it's important and when it's not.
But there are also drawbacks (message passing is terribly hard to make secure in a multi-tasking context, and is frequently slower than dirt.
While I take your point on security, to be fair, in a decent modern microkernel, message passing is a highly optimised operation. In fact, the kernel is usually optimised for precisely two tasks: scheduling and message passing. When that's pretty much all your kernel does, there are a few implementation tricks that you can use which avoids a lot of machinery that you'd otherwise find in your kernel.
Moreover, a point which is not always appreciated is that monolithic kernels often have similar costs. You still have to copy data from user space to kernel space and back again. Compare this with a modern microkernel which copies directly from address space to address space. The microkernel still needs to swap tasks, but a) it's trivial to schedule, and b) only on the x86 is swapping tasks expensive, and sometimes not even then (e.g. using L4's small address space optimisation).
IMO, microkernels and monolithic kernels are so different as to be almost incomparable.
I'm not sure what to make of that statement. I'm not suggesting that religion prescribes everything in terms of absolute truth or definitive "word of god" but that at it's root religion relys on such a truth for it's footing.
I just looked up "religion" in a few dictionaries, and the term "absolute truth" appears nowhere.
Indeed, the idea of "absolute truth" is actually a fairly recent phenomenon. If we were back in the days of tribal folk religions, we wouldn't be talking in terms of "one god". We'd be talking about "our gods" and "their gods". Before the modernist era, Christianity was still talking in those terms, though they interpreted "their gods" as being demons.
Part of the thing you have to understand is that long-lived religions are long-lived because they adapt to the time and place in which they find themselves. Christianity has always been the best at this, largely because it was the first religion not to be tied to a single ethnic group or state. (Indeed, Christianity was never designed to be tied to a state, but you try telling neo-conservatives that.)
From the "age of enlightenment" through to the modernist era, the notion of absolute truth was an intrinsic part of Western culture, and religions adopted the idea as their own, as they do.
Today, we are just past a time of change when modernism has given way to postmodernism. Most religions have adapted to this already. The rise of interest in Eastern religions and the rise of new religions loosely based on Pagan ideas, is partly because these religions already understood post-modern thought, and having less inertia. But in some places, particularly where a religion dominates, there is too much inertia to change course quickly. Groups of people will inevitably see adaptation as a loss of heritage rather than the gaining of an evolutionary advantage. Unfortunately, these people tend to be the loudest, but it was always thus.
My point in all of this is that it's a very human problem, rather than a problem inherent in religion.
Theologian's may well have a lot of questions but I'd guess they are a tiny minority in any religion.
You should not find this surprising. Experts are a tiny minority in any community.
Slashdot Mirror
First, I didn't define "freedom". Secondly, what makes you think it's "self-serving"? You don't know a damn thing about me.
AAARGH! Once again, two usages of the word "free" are being completely confused.
The GPL is free as in free speech, meaning "freedom". With freedom, as we all know, comes responsibility.
PHP/MIT/BSD et al licences are free as in free time, meaning "no (or few) strings attached".
The PHP licence is only "more free" than the GPL if you use a different meaning of "free" than that which the GPL is based on. Making statements like this just confuses people even further, so please don't do it.
Having said that, the main complaints are that a) this is yet another licence, and b) it's not compatible with the GPL. The GPL is the most common free/open source software licence around, so coming up with a new incompatible licence for your software is a barrier to your software being adopted. If you're prepared to live with that, it's fine by me. I, in turn, will feel free to consider this a deciding factor should I choose to go elsewhere.
There is no "the" preferred code. Your code may be better on some platforms, but on others it may not be.
However, you do raise a good point. A coalescing register allocator, particularly one that was sensitive to target paths, could easily optimise the temporary version to:
It's one fewer temporaries, but the same number of operations.
Exactly.
I haven't worked with GLSL et al, though I have done a lot of work with RenderMan shading language compilers, including writing two of them from scratch. I definitely agree that these shading languages are much easier to compiler compared with C++ or C. (The lack of user-defined types and recursion helps a LOT --- no fancy stack frames.) Similarly, the target platforms (usually some kind of virtual machine in the case of RenderMan) are invariably quite simple.
However, the problem is that even though the target platforms are simple, they're all extremely different. Most of them are SIMD architectures, but some are not. Some use stacks and others use register transfer. One or two (most notably Pixar's PRMan) execute annotated abstract syntax trees (called "shade trees") directly. Many compile to C++, but even then, they often have very different capabilities and limitations.
Take, for example, the following piece of code, where all of the variables are "varying" (that is, they vary over the grid being shaded):
If the target machine supports SIMD addition, then it pays to use it. So we might use a temporary, and generate code like this, scheduling the two additions separately:
If, however, you're compiling to C/C++, then you're better off scheduling the additions together:
This increases the effective size of each basic block and hence gives the C/C++ compiler a better chance of performing low-level optimisations.
And this is just showing the difference between two software VMs. I can only imagine what the differences are between the capabilities between two generations of NVIDIA hardware, let alone between NVIDIA and ATI. Leaving optimisation up to the IHV was definitely the right thing to do.
In Soviet... oh, forget it.
Actually, you could page out the ROM if you knew what you were doing.
The C64 had two ROMs: One for the kernel and one for the BASIC interpreter. It was common practice to "turn off" the interpreter ROM to give you more RAM if you were programming in assembler. It was slightly less common practice to do the same with the kernel, giving you "raw iron".
Oh, and I believe the ROMs were 8kb each, but my memory is a little fuzzy on that point.
TeX has not had a new feature added for the last 15+ years.
Sure we do. We want to get something working as quickly we can. Release early, release often.
Besides, the quicker you can write your prototype, the quicker you can get to writing the non-throw-away copy.
There are two main problems with it. First, its input format is completely incompatible with just about everything useful. This, admittedly, isn't POVRay's fault. It was written by people who didn't know better at a time when decent tools weren't generally available.
The other is that it isn't free.
Or you could have added 20 extra features and squashed 10 bugs in the Perl program, any one of which would have required rewriting large slabs of the C program in order to maintain the same performance.
Higher-level languages tend to be able to maintain performance (whether that performance is good or bad) in the face of maintenance, where a C or assembly program cannot.
Can I quote you on that?
Yours sincerely,
Ken Brown, AdTI
That's a very good point. He may have had only one year of C (which explains why his C programming style wasn't that good at the time), but he'd effectively had years of system programming experience, just not commercial experience.
I love that quote too. If you had asked Brunel if he was the "inventor" of the Great Eastern, or asked John and Washington Roebling if they were the "inventors" of the Brooklyn Bridge, they would have said "no".
Great works of engineering are rarely "inventions" in the USPTO sense of the word.
I think that's true. As Ken Brown pointed out, Linus had only a year or so of C experience at the time. As Linus has pointed out, a lot of that code embarrasses him today.
There are many reasons to go outside. Such as to justify purchase of one's gadgetry.
Did you read the original article?
The Harvard Business Review article did not claim that IT was unimportant. The main gist was that IT is not a strategic advantage to the typical business, though it once was. The reason is that everyone has it these days. It's no more a strategic advantage to your business than electricity is.
The author then argued that because everyone has it and everyone needs it, and it's not a strategic advantage, it follows that is a risk. Because it's something you have to have, and it's not a strategic advantage, it follows that the biggest concern is not having enough, but rather keeping an eye on costs. He questioned, for example, the wisdom of putting the IT guy (the confusingly-named "CIO") on the board of directors.
While I'm not defending the original article, the business environment in which it arose has given rise to two main things in US business, both of which are designed to try to minimise business risk in IT: Outsourcing, and open source.
It's usually more gigabytes than terabytes. One estimate for Monsters, Inc was that a typical frame used 2Gb of gzipped geometry and 10Gb of texture data. You do get into the terabyte range when you start dealing with digitised photographic plates, but this is Shrek@Home, not LOTR@Home.
I was also extremely impressed by Spirit. However, the most impressive, IMO, was South Park.
Bear with me, there is method in my madness.
When I said "South Park", you probably said "oh, yeah, that was computer graphics, wasn't it; I forgot about that". The illusion was so good that it looked like real cartridge paper cutouts. Remember this next time you utter the word "photorealism".
Wrong, though their renderers do solve the same kinds of problems that RenderMan-compliant renderers are supposed to solve.
For example, their shading system is based more closely on shade trees, but with very complex nodes written in C, more like Maya's hypergraph rather than Renderman SL.
Final Fantasy failed because brilliant visuals can't cover up a crap script.
It's called "Gelato" now.
1. If they released it, they'd have to support it, and they don't want to do that.
2. PDI are actually a very good citizen in the computer graphics community, unlike some companies we won't mention. They are very open about what technology they use, and they hold no (as far as I know) software patents.
"Throughput", defined as the amount of work that the system can do just prior to being overloaded, is not the quantity that everyone wants to optimise for. Performance when you are overloaded, or latency when you're not, can be more important in some systems (such as yours).
Just thought I'd mention this, because not a lot of people understand what "throughput" is, and even fewer can tell when it's important and when it's not.
While I take your point on security, to be fair, in a decent modern microkernel, message passing is a highly optimised operation. In fact, the kernel is usually optimised for precisely two tasks: scheduling and message passing. When that's pretty much all your kernel does, there are a few implementation tricks that you can use which avoids a lot of machinery that you'd otherwise find in your kernel.
Moreover, a point which is not always appreciated is that monolithic kernels often have similar costs. You still have to copy data from user space to kernel space and back again. Compare this with a modern microkernel which copies directly from address space to address space. The microkernel still needs to swap tasks, but a) it's trivial to schedule, and b) only on the x86 is swapping tasks expensive, and sometimes not even then (e.g. using L4's small address space optimisation).
IMO, microkernels and monolithic kernels are so different as to be almost incomparable.
I just looked up "religion" in a few dictionaries, and the term "absolute truth" appears nowhere.
Indeed, the idea of "absolute truth" is actually a fairly recent phenomenon. If we were back in the days of tribal folk religions, we wouldn't be talking in terms of "one god". We'd be talking about "our gods" and "their gods". Before the modernist era, Christianity was still talking in those terms, though they interpreted "their gods" as being demons.
Part of the thing you have to understand is that long-lived religions are long-lived because they adapt to the time and place in which they find themselves. Christianity has always been the best at this, largely because it was the first religion not to be tied to a single ethnic group or state. (Indeed, Christianity was never designed to be tied to a state, but you try telling neo-conservatives that.)
From the "age of enlightenment" through to the modernist era, the notion of absolute truth was an intrinsic part of Western culture, and religions adopted the idea as their own, as they do.
Today, we are just past a time of change when modernism has given way to postmodernism. Most religions have adapted to this already. The rise of interest in Eastern religions and the rise of new religions loosely based on Pagan ideas, is partly because these religions already understood post-modern thought, and having less inertia. But in some places, particularly where a religion dominates, there is too much inertia to change course quickly. Groups of people will inevitably see adaptation as a loss of heritage rather than the gaining of an evolutionary advantage. Unfortunately, these people tend to be the loudest, but it was always thus.
My point in all of this is that it's a very human problem, rather than a problem inherent in religion.
You should not find this surprising. Experts are a tiny minority in any community.