Statistically, you are marginally more likely to die in an accident if you don't wear a helmet. If you do, however, then you are more likely to be involved in an accident overall and significantly more likely to suffer permanent paralysis from an injury. The former is believed to be a combination of a perception of increased safety and reduced spacial awareness from the different airflow around your ears. The latter is because the large helmet significantly increases the torque on your neck in an accident, so impacts that would have been a mild concussion become a broken neck.
I'd be very nervous about law enforcement of any kind having 14" shotguns. With that short a barrel, the spread will be huge. It's a great weapon for a zombie apocalypse, or for urban warfare, but the first priority for law enforcement should be minimising harm to civilians, and it would be a terrible choice for this kind of usage. Even if you load it with soft ammunition, you've got a good chance of hitting someone's eye and bursting the eyeball.
When they dumped Symbian it was the *FORMER* world's most popular phone OS
That depends on when you count the dumping. Nokia had a problem that they had an OS kernel (EXA2) that was beautifully designed for mobile devices, but had a userland that was somewhat archaic and designed to work around hardware limitations that didn't really exist anymore. Their solution was to throw away the kernel and replace it with Linux. They'd already begun relegating Symbian to the low end before Android was released. They had multiple strategies internally, none of which was working and all of which were competing.
If all you want to do is build the latest release, you download the tarball. If all you want to do is use the latest release, you grab the binary. There are binaries for FreeBSD, OS X, Ubuntu and MinGW on the LLVM web site, and for a number of other systems in their respective repositories. Unlike gcc, you don't have to build it if you want a cross-compiler for some random architecture: every cross-compilation target that clang supports works with a single binary. This eliminates a significant fraction of the people who'd want to compile it themselves.
In that case, he's just plain wrong. I have two build directories where I compile LLVM itself (a large C++ codebase) with g++ and with clang++. Compiling with clang++ is at least 20% faster. It's a sufficient difference that you can tell which is running just by watching the speed of the build system output.
4.8.x doesn't help with any of those so I am not sure why they're advertising it as such.
The new -Og runs optimisations, but only those that won't destroy debug information. Previously, if you wanted -g, you were recommended to use -O0, or you lose debugging fidelity, but you sacrifice performance. -Og will be faster than -O0, but should have the same debugging fidelity. If you use -O2, then you will get worse debug output (for example, variables not able to be rematerialised in the debugger, flow control bouncing around the source code).
It's more than just the license. If all that you're doing is compiling code, then there honestly isn't much in it. Most code will be fast enough at -O0 with either compiler. For code where performance matters, there's typically less than a 10% difference between the two, and neither is always faster than the other. If, however, you want to reuse parts of the compiler, the LLVM ecosystem is a lot more friendly. For example, libclang provides a stable C API for inspecting C/C++/Objective-C source code. It's used in IDEs for syntax highlighting, refactoring, and cross-referencing, but it's also used in other languages for FFI - you can use it to get the types of C functions trivially. LLVM is easy to use as the back end for other languages, giving static and JIT compilation. It also has a very modular optimisation infrastructure, so it's easy to write an optimisation for a pattern that's common in your program or library, or specific to your source language. It's also very easy to add a back end to LLVM. The ARMv8 back end was written by one person over a few months.
clang++ is still using GNU libraries for C++ stuff.
On FreeBSD, we are shipping libc++ and libcxxrt. Our C++11 stack does not use any of the GNU C++ code.
clang is still a pain in the ass to compile, with unclear instructions,
Really? Here's how you build llvm:
$ svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm $ cd llvm/tools $ svn co http://llvm.org/svn/llvm-project/cfe/trunk clang $ cd../.. $ mkdir Build $ cmake.. $ make -j32
Optionally, add -G Ninja to the cmake line and then run ninja instead of make. This makes a huge difference to incremental builds, but only a small difference on clean builds.
and a massive, huge compile time
On my laptop, it takes about 10-15 minutes to do a clean build, on the 32-core machine I have in a rack for this kind of thing, it's about 2.
gcc on the other hand is built by automated scripts quite frequently as part of, for example, cross-toolchain builds.
You don't need to recompile clang as part of a cross-compile toolchain, it's a cross-compiler our of the box. Just add -target {target triple} to the command line, or create a {target triple}-clang symlink, and you've got a cross-compiler. In contrast, GCC uses compile-time specialisation to get the cross-compiler, so you must build it once for every target.
but i have never seen a clang->arm cross chain.
Then you have never looked at the iOS or Android SDKs, as both include clang (Android also includes GCC, iOS only supports clang).
Do you have some example applications where LLVM performance has reduced? We have a performance regression test suite, and it hasn't shown any regressions. In 3.3, we're enabling autovectorisation by default, and currently it's outperforming GCC 4.8 in LINPAC. In 3.2 and earlier, GCC and LLVM were within 10% of each other in most benchmarks, but GCC was a clear winner in cases where its autovectoriser ran in a performance critical segment.
Compilers, not so much. Build systems, absolutely. I routinely build llvm on a 32-core machine, and while each compiler or linker job is only using a single core, ninja is capable of ensuring that there is one running on every core for most of the build process. Linking tends to be the bottleneck. Of course if you're using link-time optimisation, then this is even more of a bottleneck...
However C++ is only generally much slower than C on debug builds. On builds with the full optimizer, the optimizer takes much longer to run than the parsing phase.
Not true. Templates expansion can be a significant part of compilation time. Additionally, C++ encourages a lot of things that rely on the one definition rule. For example, an inline function in C is typically only compiled if it is used, and there must be an explicit compilation unit containing the version to use when it is called but the compiler decides not to inline it. In C++, every compilation unit containing the function must emit it and then the linker will remove all except one. This means that a large project can often end up compiling (and optimising) dozens of copies of a single function in C++, only to have the linker remove all except one of them (which also increases your linking time).
The GPL v2 & 3, apply to the compiler not its output.
Not quite. They apply to the compiler and everything that is a derived work of the compiler. A compiler like gcc inserts things like specialised versions of standard functions and includes libraries for things like exception unwinding and so on. The GPL would certainly apply to these, except that GCC includes a specific exemption.
In the case of recent versions of GCC, the exemption is actually stronger. Older GCCs had an exemption to GPLv2 that only applied for code compiled with GCC. Newer ones include an exemption that applies to any 'eligible compilation process' so they can be used with other compilers too.
No. The front ends are still tied to the middle in a strange way (for example, doing constant folding in the parser, so you can't get an accurate parse tree to use in refactoring tools from the gcc front end). It's also interesting to note that two of the features that they highlighted in this release, Address Sanitizer and Thread Sanitizer are things that began life in Clang / LLVM. This is largely due to the progression of Google's shift from GCC to LLVM (these tools were developed at Google). Given that Google currently employs about half of the active GCC developers, it will be interesting to see what happens in the long run.
In theory. In practice (and this is not limited to gcc), a number of optimisations make debug information harder to make sense of. Even simple things, like common subexpression elimination, can result in debug information that is difficult to understand. Inlining, function specialisation, basic block reordering, and so on can make it hard to understand the debug info even if it's correctly preserved by all of the optimisation passes, which it isn't.
I expect it is more of a case of not being able to fully rule out a bacterial infection so they prescribe the anti-biotics to cover all their bases and to help the patient feel like their problems are being taken seriously.
It's not just that. One of my colleagues was given antibiotics for flu a few years ago. He asked the doctor why they were giving him antibiotics for a viral infection, and the doctor told him that there was a bacterial chest infection going around and people whose immune systems were weakened by the flu weren't able to fight it off. Having two lung infections in a row could easily cause serious damage, and so they prescribed antibiotics to avoid this.
Which contract? They have my first book available in both ePub and PDF formats, and my contract with my publisher specifically has a clause which prevents them from distributing it in a DRM-encumbered format. If they have added DRM, then someone in the supply chain is in breach of contract.
They're also incredibly expensive. They're charging £29.51 for the PDF and £26.03 for the ePub, which works out at $44.85 or $39.56 in US money. In contrast, if you buy it from InformIT (which is owned by my publisher), then it costs $35.19 and you get PDF, ePub and MOBI formats, all included.
My father-in-law (a well-published author across a variety of subjects from school textbooks - including some used as standard texts - to children's books to books for adults on grammar) was once refused publishing of a book because "WHSmith don't have a category for that".
I find it really surprising that WHSmiths has a non-negigible presence in book selling. The only times I've ever bought books from there have been when I received a gift voucher for them (they do the very sneaky thing, I discovered, of making their gift cards expire, but not putting an expiration date on them, which is probably not legal). Any other time I've considered buying a book there, it's been cheaper in the bookshop across the street (and much cheaper online). The only reason I can think of that they might be important is that they have a branch in pretty much every station, so people wanting to buy books to read on trains are a captive market for them.
On my old G4 PowerBook, both QuickTime and VLC could play back full screen and windows H.264 at 720p (just about) or lower (easily, using 25-50% of the CPU). Flash couldn't even handle standard definition video. GPU acceleration is fine, but there's no excuse for Flash performance. Adobe claimed that it was because Apple didn't provide adequate APIs for accessing the GPU, but this ignored two things:
Apple did provide an API for decoding H.264 and sending the result to a layer, which could then be composited in hardware.
Even without this API, Flash was a factor of 2-4 slower than other CPU-only implementations.
It turned out that their preferred design for GPU offload involved decoding H.264 on the GPU, copying the frames back to main memory, compositing them on the CPU, and then copying the resulting frames back to the CPU. As you can imagine, this was a long way from being the fastest possible solution.
Gates wrote a reasonable amount of Microsoft BASIC, which was the product that put the company on the map. He also used family connections to sell it to IBM, along with an operating system that they hadn't yet written, which implies a reasonable amount of sales skill, if not necessarily implying intelligence. He also designed and implemented the FAT filesystem in PC DOS (which later became MS DOS). Oh, and he published a paper on the optimal algorithm for flipping pancakes (which sounds silly, but is actually used in a number networking tasks). He's definitely intelligent.
Why would you want low oil prices? You want high oil prices, and to own the wells. And, by 'you', I mean the friends of the ruling party who get the contracts for rebuilding Iraq...
People don't (or, at least, shouldn't) hire consultants for routine maintenance. They hire them because they have skills that the company doesn't need full time. It is fairly common to hire consultants to do the initial design and implementation for a new system, and then have someone in-house to the maintenance. I've worked with companies that did this. Part of the job is ensuring that they have enough documentation that they don't need to call you back for simple bug fixes and feature enhancements. If they're happy that this works, then they'll call you back the next time they need something that's beyond their in-house capabilities, either because they are lacking the expertise or the manpower.
It's a shame this is at 0, because it's exactly what I would say. If it's a major client finishing up a piece of work, you want them to consider you for future pieces of work, and that includes building their next system, or extending this one when it's beyond the ability of the person that they've hired to maintain it. And even if this customer never needs more work from you, people move between companies, and you want them to think, next time they embark on a big project, 'at my last company, we had this really great consultant who shipped us working code and then trained our in-house staff to maintain it. We should see if he's available'.
Slashdot Mirror
Statistically, you are marginally more likely to die in an accident if you don't wear a helmet. If you do, however, then you are more likely to be involved in an accident overall and significantly more likely to suffer permanent paralysis from an injury. The former is believed to be a combination of a perception of increased safety and reduced spacial awareness from the different airflow around your ears. The latter is because the large helmet significantly increases the torque on your neck in an accident, so impacts that would have been a mild concussion become a broken neck.
I'd be very nervous about law enforcement of any kind having 14" shotguns. With that short a barrel, the spread will be huge. It's a great weapon for a zombie apocalypse, or for urban warfare, but the first priority for law enforcement should be minimising harm to civilians, and it would be a terrible choice for this kind of usage. Even if you load it with soft ammunition, you've got a good chance of hitting someone's eye and bursting the eyeball.
When they dumped Symbian it was the *FORMER* world's most popular phone OS
That depends on when you count the dumping. Nokia had a problem that they had an OS kernel (EXA2) that was beautifully designed for mobile devices, but had a userland that was somewhat archaic and designed to work around hardware limitations that didn't really exist anymore. Their solution was to throw away the kernel and replace it with Linux. They'd already begun relegating Symbian to the low end before Android was released. They had multiple strategies internally, none of which was working and all of which were competing.
If all you want to do is build the latest release, you download the tarball. If all you want to do is use the latest release, you grab the binary. There are binaries for FreeBSD, OS X, Ubuntu and MinGW on the LLVM web site, and for a number of other systems in their respective repositories. Unlike gcc, you don't have to build it if you want a cross-compiler for some random architecture: every cross-compilation target that clang supports works with a single binary. This eliminates a significant fraction of the people who'd want to compile it themselves.
In that case, he's just plain wrong. I have two build directories where I compile LLVM itself (a large C++ codebase) with g++ and with clang++. Compiling with clang++ is at least 20% faster. It's a sufficient difference that you can tell which is running just by watching the speed of the build system output.
Ooops, missed cd Build from the instructions.
4.8.x doesn't help with any of those so I am not sure why they're advertising it as such.
The new -Og runs optimisations, but only those that won't destroy debug information. Previously, if you wanted -g, you were recommended to use -O0, or you lose debugging fidelity, but you sacrifice performance. -Og will be faster than -O0, but should have the same debugging fidelity. If you use -O2, then you will get worse debug output (for example, variables not able to be rematerialised in the debugger, flow control bouncing around the source code).
It's more than just the license. If all that you're doing is compiling code, then there honestly isn't much in it. Most code will be fast enough at -O0 with either compiler. For code where performance matters, there's typically less than a 10% difference between the two, and neither is always faster than the other. If, however, you want to reuse parts of the compiler, the LLVM ecosystem is a lot more friendly. For example, libclang provides a stable C API for inspecting C/C++/Objective-C source code. It's used in IDEs for syntax highlighting, refactoring, and cross-referencing, but it's also used in other languages for FFI - you can use it to get the types of C functions trivially. LLVM is easy to use as the back end for other languages, giving static and JIT compilation. It also has a very modular optimisation infrastructure, so it's easy to write an optimisation for a pattern that's common in your program or library, or specific to your source language. It's also very easy to add a back end to LLVM. The ARMv8 back end was written by one person over a few months.
clang++ is still using GNU libraries for C++ stuff.
On FreeBSD, we are shipping libc++ and libcxxrt. Our C++11 stack does not use any of the GNU C++ code.
clang is still a pain in the ass to compile, with unclear instructions,
Really? Here's how you build llvm:
Optionally, add -G Ninja to the cmake line and then run ninja instead of make. This makes a huge difference to incremental builds, but only a small difference on clean builds.
and a massive, huge compile time
On my laptop, it takes about 10-15 minutes to do a clean build, on the 32-core machine I have in a rack for this kind of thing, it's about 2.
gcc on the other hand is built by automated scripts quite frequently as part of, for example, cross-toolchain builds.
You don't need to recompile clang as part of a cross-compile toolchain, it's a cross-compiler our of the box. Just add -target {target triple} to the command line, or create a {target triple}-clang symlink, and you've got a cross-compiler. In contrast, GCC uses compile-time specialisation to get the cross-compiler, so you must build it once for every target.
but i have never seen a clang->arm cross chain.
Then you have never looked at the iOS or Android SDKs, as both include clang (Android also includes GCC, iOS only supports clang).
Do you have some example applications where LLVM performance has reduced? We have a performance regression test suite, and it hasn't shown any regressions. In 3.3, we're enabling autovectorisation by default, and currently it's outperforming GCC 4.8 in LINPAC. In 3.2 and earlier, GCC and LLVM were within 10% of each other in most benchmarks, but GCC was a clear winner in cases where its autovectoriser ran in a performance critical segment.
Compilers, not so much. Build systems, absolutely. I routinely build llvm on a 32-core machine, and while each compiler or linker job is only using a single core, ninja is capable of ensuring that there is one running on every core for most of the build process. Linking tends to be the bottleneck. Of course if you're using link-time optimisation, then this is even more of a bottleneck...
However C++ is only generally much slower than C on debug builds. On builds with the full optimizer, the optimizer takes much longer to run than the parsing phase.
Not true. Templates expansion can be a significant part of compilation time. Additionally, C++ encourages a lot of things that rely on the one definition rule. For example, an inline function in C is typically only compiled if it is used, and there must be an explicit compilation unit containing the version to use when it is called but the compiler decides not to inline it. In C++, every compilation unit containing the function must emit it and then the linker will remove all except one. This means that a large project can often end up compiling (and optimising) dozens of copies of a single function in C++, only to have the linker remove all except one of them (which also increases your linking time).
The GPL v2 & 3, apply to the compiler not its output.
Not quite. They apply to the compiler and everything that is a derived work of the compiler. A compiler like gcc inserts things like specialised versions of standard functions and includes libraries for things like exception unwinding and so on. The GPL would certainly apply to these, except that GCC includes a specific exemption.
In the case of recent versions of GCC, the exemption is actually stronger. Older GCCs had an exemption to GPLv2 that only applied for code compiled with GCC. Newer ones include an exemption that applies to any 'eligible compilation process' so they can be used with other compilers too.
Even the standard was late. C++0x was released in 2011...
No. The front ends are still tied to the middle in a strange way (for example, doing constant folding in the parser, so you can't get an accurate parse tree to use in refactoring tools from the gcc front end). It's also interesting to note that two of the features that they highlighted in this release, Address Sanitizer and Thread Sanitizer are things that began life in Clang / LLVM. This is largely due to the progression of Google's shift from GCC to LLVM (these tools were developed at Google). Given that Google currently employs about half of the active GCC developers, it will be interesting to see what happens in the long run.
In theory. In practice (and this is not limited to gcc), a number of optimisations make debug information harder to make sense of. Even simple things, like common subexpression elimination, can result in debug information that is difficult to understand. Inlining, function specialisation, basic block reordering, and so on can make it hard to understand the debug info even if it's correctly preserved by all of the optimisation passes, which it isn't.
I expect it is more of a case of not being able to fully rule out a bacterial infection so they prescribe the anti-biotics to cover all their bases and to help the patient feel like their problems are being taken seriously.
It's not just that. One of my colleagues was given antibiotics for flu a few years ago. He asked the doctor why they were giving him antibiotics for a viral infection, and the doctor told him that there was a bacterial chest infection going around and people whose immune systems were weakened by the flu weren't able to fight it off. Having two lung infections in a row could easily cause serious damage, and so they prescribed antibiotics to avoid this.
Which contract? They have my first book available in both ePub and PDF formats, and my contract with my publisher specifically has a clause which prevents them from distributing it in a DRM-encumbered format. If they have added DRM, then someone in the supply chain is in breach of contract.
They're also incredibly expensive. They're charging £29.51 for the PDF and £26.03 for the ePub, which works out at $44.85 or $39.56 in US money. In contrast, if you buy it from InformIT (which is owned by my publisher), then it costs $35.19 and you get PDF, ePub and MOBI formats, all included.
My father-in-law (a well-published author across a variety of subjects from school textbooks - including some used as standard texts - to children's books to books for adults on grammar) was once refused publishing of a book because "WHSmith don't have a category for that".
I find it really surprising that WHSmiths has a non-negigible presence in book selling. The only times I've ever bought books from there have been when I received a gift voucher for them (they do the very sneaky thing, I discovered, of making their gift cards expire, but not putting an expiration date on them, which is probably not legal). Any other time I've considered buying a book there, it's been cheaper in the bookshop across the street (and much cheaper online). The only reason I can think of that they might be important is that they have a branch in pretty much every station, so people wanting to buy books to read on trains are a captive market for them.
It turned out that their preferred design for GPU offload involved decoding H.264 on the GPU, copying the frames back to main memory, compositing them on the CPU, and then copying the resulting frames back to the CPU. As you can imagine, this was a long way from being the fastest possible solution.
Gates wrote a reasonable amount of Microsoft BASIC, which was the product that put the company on the map. He also used family connections to sell it to IBM, along with an operating system that they hadn't yet written, which implies a reasonable amount of sales skill, if not necessarily implying intelligence. He also designed and implemented the FAT filesystem in PC DOS (which later became MS DOS). Oh, and he published a paper on the optimal algorithm for flipping pancakes (which sounds silly, but is actually used in a number networking tasks). He's definitely intelligent.
Why would you want low oil prices? You want high oil prices, and to own the wells. And, by 'you', I mean the friends of the ruling party who get the contracts for rebuilding Iraq...
People don't (or, at least, shouldn't) hire consultants for routine maintenance. They hire them because they have skills that the company doesn't need full time. It is fairly common to hire consultants to do the initial design and implementation for a new system, and then have someone in-house to the maintenance. I've worked with companies that did this. Part of the job is ensuring that they have enough documentation that they don't need to call you back for simple bug fixes and feature enhancements. If they're happy that this works, then they'll call you back the next time they need something that's beyond their in-house capabilities, either because they are lacking the expertise or the manpower.
It's a shame this is at 0, because it's exactly what I would say. If it's a major client finishing up a piece of work, you want them to consider you for future pieces of work, and that includes building their next system, or extending this one when it's beyond the ability of the person that they've hired to maintain it. And even if this customer never needs more work from you, people move between companies, and you want them to think, next time they embark on a big project, 'at my last company, we had this really great consultant who shipped us working code and then trained our in-house staff to maintain it. We should see if he's available'.