ps and top generally use platform-specific non-POSIX interfaces. They are written for the specific kernel, and use things like kvm or procfs to get that data. The compiler, in contrast, is expected to run on a large range of operating systems. There is also no standard way of the OS notifying processes that memory is low. OS X will deliver a message on a specific Mach port in this case, which makes it relatively easy to handle, but if you want this to work everywhere then it will need some effort (including modifying the kernel on many systems).
Uh, C and C++ are per-file languages. That said, GCC (and clang) do support precompiled headers, which seem to be what you are rambling about. If you have a project header, you can pre-parse it and automatically add it to the start of every source file pretty trivially.
That's out of date. -O4 will enable link-time optimisations these days, which can make a big difference (assuming that you entire toolchain supports it).
The problem with -O3 (in GCC) is that it enables optimisations that revolve around various bits of undefined behaviour in the spec. Lots of programmers aren't aware of these bits of undefined behaviour (e.g. overflow of unsigned values) and expect some well-defined behaviour in their code. This code will run fine on a compiler that makes the same assumptions that they do (e.g. wrap-on-overflow behaviour for all integer types, or float* may alias int*), but won't when you turn up the optimiser.
It is usually the case that code that works at one optimisation level but not another is wrong, but often the wrongness can be very subtle.
"can this function ever throw?" - it's been a while since I went scratching through an object or class file, but wouldn't the compiler already know this from previous compiles?
How? Unless the programmer has tagged it as not throwing (throw() or __attribute__((nothrow)) ) then the only way to determine this is to walk the call graph from that function down until you find a function that does throw, or you explore all nodes until every leaf is guaranteed not to throw. This requires you to have the AST (or the IR) for that function and every function further down the call graph in memory.
What I want is all software to build the same way, consistently and that's why the *BSD folks began work on their own toolchain
Okay, speaking as one of those [Free]BSD guys working on the toolchain... bullshit. Consistency is important, and nothing is more important than producing correct code, but producing fast code comes a close second (producing correct code quickly is also important for fast compile-debug cycles).
Inlining and function specialisation are both important optimisations. For example, if half the time a function is called, one of the parameters is a constant, you can emit a custom version that does propagation of that constant all of the way through and get vastly simpler code. For functions that are not exported outside of a library, you can change their calling convention to a faster one, but only if you can control every possible callsite.
All of these work better when you can do whole-program (or, at least, whole-library) optimisation. When you're talking about a mobile platform, performance means battery life. If you improve performance, you can put the CPU in a low-power state more often, and the battery lasts longer. This is really important.
So give me a toolchain that builds things strictly as written so I can see where the lag points are.
Any compiler does this. If you're writing a C-family language, then you might want to check the parts of the spec that are undefined behaviour. There are a lot.
-pipe just means that the compiler writes the assembly to the assembler's standard input (if you use a less archaic compiler, it will emit object code directly, not invoke an external assembler, but if you're stuck with gcc...). It won't use much more RAM, just enough to run the assembler on top of the amount required to run the compiler.
More likely, they've turned on link-time optimisation. For big projects, this can use an insane amount of memory - the compiler basically has to load the intermediate representation of the entire program into memory at once and analyse it.
Oh, and for C++ projects, the linker can take a lot more memory than the compiler.
Different economics tomorrow is not a reason for doing something today. For importing stuff from space to be worthwhile, we'd basically need a working space elevator. That is at least a decade of material science developments away and even more in terms of design and construction. More importantly, it would obsolete anything that we can build now, in terms of space vehicle.
Your argument is like suggesting investing heavily in wooden sailing ships to transport coal.
No, the ROI from sending manned missions to celestial objects is much easier to determine that Columbus' voyage. We know that there is no macroscopic life anywhere that we can get to with a manned mission off Earth. We know the relative abundances of minerals anywhere that we could get to with a manned mission. We know that it's not even remotely economical to import any of them to Earth. At this point the only vaguely plausible justification for manned missions is 'we might come up with some secondary technologies that are useful', but that justification works just as well for investing in R&D that also has some useful outcomes as its primary outcome.
I don't have a study, but I found my essay marks went from a C to B average to A to A* average when I was allowed to type essays instead of writing them by hand. I was able to think about the content and the structure of the language, rather than about the mechanics of moving a pen across paper. I'm now about to have my fourth book published. I learned to program when I was seven by having a teacher show us how to write some simple programs on a computer in the classroom. I now do a fair amount of contract programming.
Nope. A trade route to China was known to be worthwhile - that's why lots of people were trying to find one. The only resistance to Columbus came from people who pointed out that the diameter of the Earth had been measured accurately repeatedly since the greeks, and all of those measurements said that he'd run out of food and starve about half way to China.
He was very fortunate to find a habitable continent on the way. That is simply not going to happen in space. Maps of the ocean were astonishingly primitive then. You can only see a few miles in any direction from a ship and you could only make maps where ships had gone (and, even then, the position could easily be tens of miles off). In contrast, we have the ability to observe anywhere that we might consider sending manned explorers to.
More importantly though, robotic explorers, if they'd been available, could have done a much better job than Columbus. The first mapping satellites gave us detailed images of places deep in jungles and deserts that were difficult to get to. Humans were only needed when it came to settling, and we're a way away from having humans settle in space.
If they don't reinstate it, then they put their safe harbour status in jeopardy. If they are not classed as a safe harbour by the DMCA then they, not the original uploaders, are liable for any copyright infringement.
Actually, it's not quite so simple. If you post anything people upload, then you are covered by the Safe Harbour provisions of the DMCA. If someone files a take-down notice, then you are obliged to remove it, until the original poster produces a counter notice. If you then restore it, then the copyright owner has to get a court to agree that it is infringement (by suing the original poster). If you don't, then you may be deemed to be taking an active role in copyright enforcement and lose your safe harbour status. In short, not restoring it can open Google up to more liability than restoring it.
There are two places where airships have an advantage over jets:
The first is carrying a lot of cargo that isn't particularly urgent. Modern designs can go at about 80 miles per hour, which competes well with any form of ground transport - even trains once you remember that they can go in a straight line - and they can do this all day, and this adds up to quite long distances.
The second is tourist travel. Think of an airship like a cruise ship that can go over land. Quite often, being able to see the scenery moving slowly by is a selling point.
A modern airship would not be covered in extremely flammable cellulose nitrate.
Exactly. If you look at the newsreel of the Hindenburg disaster, you can see it obviously on fire. Hydrogen does not burn like that. It explodes. Small hydrogen leaks can even act as fire suppressants, because the explosion blows out nearby fires (and makes a loud pop). Getting a steady flame from hydrogen is really hard, as anyone who has destroyed glass equipment in a chemistry lab trying knows.
I'd have thought hydrogen made more sense for a solar powered airship, because you can top it up easily by electrolysing sea water. Helium gives less lift, is more expensive, harder to obtain, and not really much safer. If the hydrogen balloon is not surrounded by anything inflammable, then even a big leak will just cause the hydrogen to escape (quickly, upwards) and cause the airship to coast towards the ground.
How cheap are those microcontrollers? A 100MHz ARM core with enough flash and RAM on die to run a full operating system is about $1. Even if the microcontroller is free, you're going to have to ship tens of thousands before it becomes cheaper overall, when you factor in the cost of the development.
The code is here. The AST / back end are in LanguageKit, the Smalltalk front end is in Smalltalk (this also contains a few support things that make OpenStep classes look a bit more like Smalltalk-80 ones). The JavaScript-like language is in EScript, but it may not be working at the moment. It currently requires a trunk build of GNUstep libobjc, but I plan on releasing 1.6 of the runtime Real Soon Now.
I bought three 2TB hard disks two weeks ago (RAID-Z+dedup) and they seem to be about 20% more expensive now than when I bought them. To be honest, I don't think the change would have made any difference to me. 2TB is still the sweet spot. Mind you, 1TB was the sweet spot when I started thinking about building this machine, so it might have given me a reason to procrastinate for a few more months...
It seems fairly clear that the only ones who stand to gain and are adamant on attacking the scientists are corporations selling oil, cars, and their lobbyists
Not at all. There are lots of people who stand to gain from putting their fingers in their ears and saying 'lalalalala I'm not listening'. Reducing greenhouse gas emission is expensive. If you are doing a lot of manufacturing - or consuming the products of manufacturing - then it's going to put your costs up. Even delaying legislation mandating such a reduction by a few years can save a lot of companies millions of dollars.
I wonder if older compilers like GCC will be able to adapt or if they'll just continue being monolithic.
GCC intentionally resisted clean separation and layering because someone might do something evil like create a GPL'd program that did syntax highlighting and invoke it via a pipe from a proprietary program. As a side effect, this made it impossible to integrate into Free IDEs[1]. In response to LLVM and Clang being vastly better for this kind of thing, the GCC team has finally allowed you to write plugins, but it's a bit late. About the only reason to use GCC these days is if you really need to target one of the obscure architectures that it supports. If you care about performance, EKOPath or Open64 is a lot better. If you care about features and modularity, Clang/LLVM is better (and ENZO is even better, but not Free).
[1] The biggest difference between the GPL and BSD licensing philosophies: The GPL is intended to make writing proprietary software hard, the BSDL is intended to make writing free software easy.
Uh, clang is 'libraryized'. The clang binary is a tiny wrapper around the various libraries. It's pretty simple to write a replacement or to embed the libraries in something else. Look at Cling, for example, which implements a C++ REPL system using the libraries, or LLDB, which uses clang to parse [Objective-]C[++] expressions in the debugger.
If the grandparent thinks any of this is easy with gcc, then he's never tried hacking on gcc - even using it for syntax highlighting is almost impossible because the gcc team intentionally avoids clean layering incase someone uses their code evil proprietary programs.
LLVM is a better example. It's a set of libraries for generating a code in an intermediate representation, transforming that representation (usually for optimisation, but also for instrumentation and other things) and then emitting it as object code, assembly, or JIT'd executable code in memory. I've written compilers for Smalltalk and for a toy JavaScript-like language using it, and they share the same set of optimisations that I wrote for Objective-C and the same object model. The total amount of Smalltalk-specific code is about 15KLoC (including comments).
It absolutely makes sense for a busy server, but not really for a home NAS. Adding a SSD for the ZIL might make sense though, because Time Machine backups tend to be about 20MB and they wake up the disks.
Slashdot Mirror
ps and top generally use platform-specific non-POSIX interfaces. They are written for the specific kernel, and use things like kvm or procfs to get that data. The compiler, in contrast, is expected to run on a large range of operating systems. There is also no standard way of the OS notifying processes that memory is low. OS X will deliver a message on a specific Mach port in this case, which makes it relatively easy to handle, but if you want this to work everywhere then it will need some effort (including modifying the kernel on many systems).
Uh, C and C++ are per-file languages. That said, GCC (and clang) do support precompiled headers, which seem to be what you are rambling about. If you have a project header, you can pre-parse it and automatically add it to the start of every source file pretty trivially.
That's out of date. -O4 will enable link-time optimisations these days, which can make a big difference (assuming that you entire toolchain supports it).
The problem with -O3 (in GCC) is that it enables optimisations that revolve around various bits of undefined behaviour in the spec. Lots of programmers aren't aware of these bits of undefined behaviour (e.g. overflow of unsigned values) and expect some well-defined behaviour in their code. This code will run fine on a compiler that makes the same assumptions that they do (e.g. wrap-on-overflow behaviour for all integer types, or float* may alias int*), but won't when you turn up the optimiser.
It is usually the case that code that works at one optimisation level but not another is wrong, but often the wrongness can be very subtle.
"can this function ever throw?" - it's been a while since I went scratching through an object or class file, but wouldn't the compiler already know this from previous compiles?
How? Unless the programmer has tagged it as not throwing (throw() or __attribute__((nothrow)) ) then the only way to determine this is to walk the call graph from that function down until you find a function that does throw, or you explore all nodes until every leaf is guaranteed not to throw. This requires you to have the AST (or the IR) for that function and every function further down the call graph in memory.
What I want is all software to build the same way, consistently and that's why the *BSD folks began work on their own toolchain
Okay, speaking as one of those [Free]BSD guys working on the toolchain... bullshit. Consistency is important, and nothing is more important than producing correct code, but producing fast code comes a close second (producing correct code quickly is also important for fast compile-debug cycles).
Inlining and function specialisation are both important optimisations. For example, if half the time a function is called, one of the parameters is a constant, you can emit a custom version that does propagation of that constant all of the way through and get vastly simpler code. For functions that are not exported outside of a library, you can change their calling convention to a faster one, but only if you can control every possible callsite.
All of these work better when you can do whole-program (or, at least, whole-library) optimisation. When you're talking about a mobile platform, performance means battery life. If you improve performance, you can put the CPU in a low-power state more often, and the battery lasts longer. This is really important.
So give me a toolchain that builds things strictly as written so I can see where the lag points are.
Any compiler does this. If you're writing a C-family language, then you might want to check the parts of the spec that are undefined behaviour. There are a lot.
-pipe just means that the compiler writes the assembly to the assembler's standard input (if you use a less archaic compiler, it will emit object code directly, not invoke an external assembler, but if you're stuck with gcc...). It won't use much more RAM, just enough to run the assembler on top of the amount required to run the compiler.
More likely, they've turned on link-time optimisation. For big projects, this can use an insane amount of memory - the compiler basically has to load the intermediate representation of the entire program into memory at once and analyse it.
Oh, and for C++ projects, the linker can take a lot more memory than the compiler.
Different economics tomorrow is not a reason for doing something today. For importing stuff from space to be worthwhile, we'd basically need a working space elevator. That is at least a decade of material science developments away and even more in terms of design and construction. More importantly, it would obsolete anything that we can build now, in terms of space vehicle.
Your argument is like suggesting investing heavily in wooden sailing ships to transport coal.
No, the ROI from sending manned missions to celestial objects is much easier to determine that Columbus' voyage. We know that there is no macroscopic life anywhere that we can get to with a manned mission off Earth. We know the relative abundances of minerals anywhere that we could get to with a manned mission. We know that it's not even remotely economical to import any of them to Earth. At this point the only vaguely plausible justification for manned missions is 'we might come up with some secondary technologies that are useful', but that justification works just as well for investing in R&D that also has some useful outcomes as its primary outcome.
I don't have a study, but I found my essay marks went from a C to B average to A to A* average when I was allowed to type essays instead of writing them by hand. I was able to think about the content and the structure of the language, rather than about the mechanics of moving a pen across paper. I'm now about to have my fourth book published. I learned to program when I was seven by having a teacher show us how to write some simple programs on a computer in the classroom. I now do a fair amount of contract programming.
Nope. A trade route to China was known to be worthwhile - that's why lots of people were trying to find one. The only resistance to Columbus came from people who pointed out that the diameter of the Earth had been measured accurately repeatedly since the greeks, and all of those measurements said that he'd run out of food and starve about half way to China.
He was very fortunate to find a habitable continent on the way. That is simply not going to happen in space. Maps of the ocean were astonishingly primitive then. You can only see a few miles in any direction from a ship and you could only make maps where ships had gone (and, even then, the position could easily be tens of miles off). In contrast, we have the ability to observe anywhere that we might consider sending manned explorers to.
More importantly though, robotic explorers, if they'd been available, could have done a much better job than Columbus. The first mapping satellites gave us detailed images of places deep in jungles and deserts that were difficult to get to. Humans were only needed when it came to settling, and we're a way away from having humans settle in space.
If they don't reinstate it, then they put their safe harbour status in jeopardy. If they are not classed as a safe harbour by the DMCA then they, not the original uploaders, are liable for any copyright infringement.
Actually, it's not quite so simple. If you post anything people upload, then you are covered by the Safe Harbour provisions of the DMCA. If someone files a take-down notice, then you are obliged to remove it, until the original poster produces a counter notice. If you then restore it, then the copyright owner has to get a court to agree that it is infringement (by suing the original poster). If you don't, then you may be deemed to be taking an active role in copyright enforcement and lose your safe harbour status. In short, not restoring it can open Google up to more liability than restoring it.
There are two places where airships have an advantage over jets:
The first is carrying a lot of cargo that isn't particularly urgent. Modern designs can go at about 80 miles per hour, which competes well with any form of ground transport - even trains once you remember that they can go in a straight line - and they can do this all day, and this adds up to quite long distances.
The second is tourist travel. Think of an airship like a cruise ship that can go over land. Quite often, being able to see the scenery moving slowly by is a selling point.
A modern airship would not be covered in extremely flammable cellulose nitrate.
Exactly. If you look at the newsreel of the Hindenburg disaster, you can see it obviously on fire. Hydrogen does not burn like that. It explodes. Small hydrogen leaks can even act as fire suppressants, because the explosion blows out nearby fires (and makes a loud pop). Getting a steady flame from hydrogen is really hard, as anyone who has destroyed glass equipment in a chemistry lab trying knows.
I'd have thought hydrogen made more sense for a solar powered airship, because you can top it up easily by electrolysing sea water. Helium gives less lift, is more expensive, harder to obtain, and not really much safer. If the hydrogen balloon is not surrounded by anything inflammable, then even a big leak will just cause the hydrogen to escape (quickly, upwards) and cause the airship to coast towards the ground.
That's not a much lower spec than the Xerox Alto, and it ran a complete GUI written in Smalltalk, an introspective IDE, and some apps.
How cheap are those microcontrollers? A 100MHz ARM core with enough flash and RAM on die to run a full operating system is about $1. Even if the microcontroller is free, you're going to have to ship tens of thousands before it becomes cheaper overall, when you factor in the cost of the development.
The code is here. The AST / back end are in LanguageKit, the Smalltalk front end is in Smalltalk (this also contains a few support things that make OpenStep classes look a bit more like Smalltalk-80 ones). The JavaScript-like language is in EScript, but it may not be working at the moment. It currently requires a trunk build of GNUstep libobjc, but I plan on releasing 1.6 of the runtime Real Soon Now.
I periodically write things about it on the Étoilé blog. You can also read some slightly out of date slides from a talk I gave about it at FOSDEM in 2009, and some more current ones from ESUG this year. Drop me an email if you've got any more questions.
I bought three 2TB hard disks two weeks ago (RAID-Z+dedup) and they seem to be about 20% more expensive now than when I bought them. To be honest, I don't think the change would have made any difference to me. 2TB is still the sweet spot. Mind you, 1TB was the sweet spot when I started thinking about building this machine, so it might have given me a reason to procrastinate for a few more months...
It seems fairly clear that the only ones who stand to gain and are adamant on attacking the scientists are corporations selling oil, cars, and their lobbyists
Not at all. There are lots of people who stand to gain from putting their fingers in their ears and saying 'lalalalala I'm not listening'. Reducing greenhouse gas emission is expensive. If you are doing a lot of manufacturing - or consuming the products of manufacturing - then it's going to put your costs up. Even delaying legislation mandating such a reduction by a few years can save a lot of companies millions of dollars.
I wonder if older compilers like GCC will be able to adapt or if they'll just continue being monolithic.
GCC intentionally resisted clean separation and layering because someone might do something evil like create a GPL'd program that did syntax highlighting and invoke it via a pipe from a proprietary program. As a side effect, this made it impossible to integrate into Free IDEs[1]. In response to LLVM and Clang being vastly better for this kind of thing, the GCC team has finally allowed you to write plugins, but it's a bit late. About the only reason to use GCC these days is if you really need to target one of the obscure architectures that it supports. If you care about performance, EKOPath or Open64 is a lot better. If you care about features and modularity, Clang/LLVM is better (and ENZO is even better, but not Free).
[1] The biggest difference between the GPL and BSD licensing philosophies: The GPL is intended to make writing proprietary software hard, the BSDL is intended to make writing free software easy.
Uh, clang is 'libraryized'. The clang binary is a tiny wrapper around the various libraries. It's pretty simple to write a replacement or to embed the libraries in something else. Look at Cling, for example, which implements a C++ REPL system using the libraries, or LLDB, which uses clang to parse [Objective-]C[++] expressions in the debugger.
If the grandparent thinks any of this is easy with gcc, then he's never tried hacking on gcc - even using it for syntax highlighting is almost impossible because the gcc team intentionally avoids clean layering incase someone uses their code evil proprietary programs.
LLVM is a better example. It's a set of libraries for generating a code in an intermediate representation, transforming that representation (usually for optimisation, but also for instrumentation and other things) and then emitting it as object code, assembly, or JIT'd executable code in memory. I've written compilers for Smalltalk and for a toy JavaScript-like language using it, and they share the same set of optimisations that I wrote for Objective-C and the same object model. The total amount of Smalltalk-specific code is about 15KLoC (including comments).
Gee, it looks like $3,799.00 to me, must be the font I use
Or maybe you have an MSDN subscription already? That's the price for renewal, the grandparent's price is the one for a new subscription.
It absolutely makes sense for a busy server, but not really for a home NAS. Adding a SSD for the ZIL might make sense though, because Time Machine backups tend to be about 20MB and they wake up the disks.