Re:I just want C++ programs to COMPILE faster
on
GCC 4.0 Preview
·
· Score: 2, Informative
I've found that for C++ projects on the low side of medium (say, around 50,000 lines), arranging the compilation so that all of the source code is lumped into a single "unit" accelerates GCC's from-scratch compilation times considerably. Of course, it also uses large amounts of RAM.
For example, direct GCC to compile one top-level.cpp file containing hundreds of
#include "other-source-file-0.cpp"
#include "other-source-file-1.cpp"
#include "other-source-file-....cpp"
#include "other-source-file-673.cpp" statements, one for each.cpp file in the entire project.
This forces GCC to compile the whole program as a single unit, so it preprocesses the headers only once, and generates only a single object file.
This achieves approximately the same reductions in compile time as precompiled headers.
Come link time (which can be quite long even for a medium-sized project), instead of needing to combine hundreds of object files, the linker need only deal with one. On x86-Linux with GCC 3.4.x, at least, this accelerates the linking process, plus generates a much smaller and slightly faster binary. I assume that the slight acceleration in the generated code is due to the fact that compiling the entire project as one compilation unit has essentially the same cross-unit optimization benefits as link-time code generation.
Although this technique reduces from-scratch compile times considerably, it's of dubious value in most situations because:
a) Users compiling the software as part of an installation process might find it uncomfortable--or even impossible--to allow the compiler several hundred MB RAM.
b) The developer's changes in a typical edit-compile-test cycle are localized. This technique destroys the possibility of using previously compiled object files for those compilation units whose source code hasn't changed, since there's only one compilation unit for the entire project.
You're quite right that Java's speed is excellent these days (for non-GUI code, at least). I've spent a lot of time recently working with a large system that was first implemented in Java (by highly skilled developers) and then ported to C++ (by greenhorns). The C++ port is only 50-100% faster, which isn't worth the price in developer time that's been wasted on memory leaks and other forms of memory corruption that were never a factor in Java. Besides that, supporting multiple platforms with the C++ version is the #definition of pain.
However, the C++ version uses only about 1/4 or 1/5 as much memory as the Java version, and starts up far more quickly. If a *desktop* application needs to be deployed on older machines, or if the application is so memory-intensive it taxes the limits of today's server hardware, Java still falls flat.
Exercise is almost never bad for a person, and does help one fall asleep, but that's not the issue with sleep apnea.
Sleep apnea causes a person who's already sleeping to stop breathing (or have great difficulty), at which point the brain wakes the body up, and the body resumes breathing. This can happen dozens or more times a night.
So even if the victim is able to fall asleep five minutes after his head hits the pillow, he still can't get rest, because REM is constantly disrupted.
The problem with.NET or Java as a solution to the library problem is that you end up using your functional language:
1) On a proprietary runtime. In the case of.NET, it's also a platform-specific runtime. Don't even bother mentioning Mono; the Microsoft Corporation that exists in the universe I inhabit will never allow Mono to grow into anything more than a token antitrust smoke screen, a perpetually not-quite-ready, not-quite-compatible runner-up. If you expect Microsoft to behave differently, you must not be referring to the corporation that's been systematically raping its competitors by whatever means necessary for the last two decades. The safest elements of.NET--those that have been submitted to ECMA--exclude almost all useful libraries.
2) With libraries that were designed for consumption by object-oriented client languages, which robs the would-be functional programmer of much of the value of the functional way. The programming experience degenerates into a sad parody of functional programming that really amounts to object-oriented programming through a functional condom. To paraphrase the famous quote about condoms, "Functional programming with object-oriented libraries is armor against productivity, gossamer against library scarcity."
3) On a runtime that performs 3-10 times worse than a runtime designed for the langauge in question.
Yes, I've been intrigued by OCaml for a long time.
OCaml's major problem is that, like every other functional language available today, the breadth of its standard library and third-party libraries is totally pathetic in comparison to the likes of Java and Python. The same limitation applies to Lisp, Scheme, Haskell, Erlang, etc.
These languages face a Catch-22: until they're more popular, they won't attract enough developers to ameliorate the library situation, yet until they offer better libraries, they won't attract developers. Historically, this barrier has been surmounted in one of two ways: either a deep-pocketed corporation subsidizes library development until the language gains momentum (see Java, C#) or the languages are sufficiently "charming"/"hip" that the library support appears as a result of a grass-roots effort (see Perl, Python).
Is there any realistic prospect that one of the functional languages I mentioned will strike it rich in either of those ways? It doesn't seem likely to me.
The reason you would NOT opt for a single 6800GT is that the performance of a SINGLE 6800 is substantially less than DUAL 6600s.
Bullshit! I certainly haven't seen any benchmarks that support your assertion. Did you even look at the benchmarks I linked to? In most cases, dual 6600 GTs perform slightly worse than a single 6800 GT.
The 6600 cards are pretty reasonably priced, so picking up two of them and getting 180% performance of a single 6600GT AGP is pretty attractive...
No, it isn't. According to reputable benchmarks, dual 6600 GTs ($200 x 2) typically perform slightly worse than a single 6800 GT ($400 x 1).
Why would you accept the undoubtedly higher power consumption of dual 6600 GTs versus a single 6800 GT, when the price is about the same?
Those who can afford a new motherboard (and probably a new CPU) just for the SLI capability won't be stooping to 6600 GTs; they'll opt for something better.
Java is a nearly total failure at desktop applications, and will remain so, because Sun doesn't give a damn about enabling native Java apps to deliver user experiences comparable to those offered by native apps.
Every day I use one of the most successful Java desktop applications (jEdit), and like it very much. So it should tell us something when the author of that application, Slava Pestov, advises programmers to "just give up" on Java for the desktop:
It is clear that Java was never practical for developing real applications, and never will be. Instead of asking how you can revive something that's obviously dead and gotten much more hype than it deserves, you should be asking if there's better technology out there.
and the rest of the Simplified Wrapper and Interface Generator (SWIG) team.
If you use Python, Perl, PHP, Ruby, or TCL chances are you use a multitude of libraries that would've been prohibitively laborious to wrap without SWIG.
The command line C++ compiler was never included in the SDK. The C# compiler and so on were, however.
That's incorrect. The.NET SDK has always included the C++ compiler (installed by default to C:\Program Files\Microsoft Visual Studio.NET 200x\Vc7), but the compiler was the Standard Edition, without an optimizer. If you pass it an optimization switch, the Standard Edition issues a warning to the effect that "The Standard Edition of Microsoft Visual C++ does not include an optimizer.". Naturally, lack of an optimizer makes the Standard Edition almost useless for production code.
This newly released command-line compiler includes a fully functional optimizer. It's the same C++ compiler that underlies VC++.NET 2003 Professional.
How does a critical vulnerability happen? Seriously. Is there a URL someone can provide or a good description that shows what it takes to make an OS or application with a vulnerability?
Of course there's an infinite number of ways to write a vulnerable program, but the most common is to run afoul of a buffer overflow. A buffer overflow is a relatively simple flaw, but it's an easy mistake to make in C and C++ because those languages give economy of computational resources precedence over every other consideration, including security and stability.
There's an illustrated and fairly concise introduction to buffer overflows at LinuxJournal.
I'm not quite sure what it offers over PostgreSQL.
distributed transactions (these are indispensable for reliable distributed object programming (I do a lot))
savepoints (elementary form of nested transactions)
native Windows support
embedded mode (the database engine is capable of running as an in-process library rather than a standalone server)
It's difficult to work with from an administrative level, and not terribly well documented...
I agree that the documentation is mediocre, but firmly disagree that it's hard to administer. The key is: don't. Make a couple of changes in the config file if you need to, configure automatic backups, then forget about it.
What's next? A BSD-is-dead troll getting linked on the front page?
More likely, the next story will be about some guy named Rob Enderle announcing the death of Bluetooth.
Re:Its not redundant
on
How C# Was Made
·
· Score: 3, Informative
In your example, I know with complete certainty that I am creating a new "Type" and assigning it to the variable "varName". This is not the case if it used the syntax of Python. How do you know I am not calling a method called "Type"?
You don't know, and you shouldn't.
Suppose at first you do, in fact, instantiate a new object via the 'Type()' call. Later, during the optimization phase, you discover that in most cases you can return a reference to a pre-existing, pooled object. In Python, you can make that change without breaking client code; not so when object creation is explicitly annotated.
As to whether Type is a method, function, or class constructor, it doesn't matter as long as the returned objects implement the required interface.
Dynamic typing being a Good Thing depends on the context. Dynamic typing tends to move more bugs which could easily be caught at compile time to runtime. This means more testing needs to be done which actually drives up development costs and thus negates any benefit gained from "rapid development".
Indeed, I find that writing test suites saps much of the development speed advantage I gain from using a dynamically typed language.
However, using a soundly designed dynamic language, I can write dynamic-implementation+test-suite in about the same time I could write only static-implementation in, say, Java. But since I have an extensive test suite, I end up with much more reliable code.
You can see official AMD benchmark results of various programs running on Windows XP 32-bit edition vs. Windows XP 64-bit edition beginning on page 36 of this PDF. The results have three columns: time in seconds on WinXP 32-bit w/ 32-bit executable, time in seconds on WinXP 64-bit with 32-bit executable, and time in seconds on WinXP 64-bit with 64-bit executable.
You can see official AMD benchmark results of various programs running on Windows XP 32-bit edition vs. Windows XP 64-bit edition beginning of page 36 of this PDF. The results have three columns: time in seconds on WinXP 32-bit w/ 32-bit executable, time in seconds on WinXP 64-bit with 32-bit executable, and time in seconds on WinXP 64-bit with 64-bit executable.
The results are quite impressive, but I'm not sure we can trust AMD, since obviously they want AMD64 to look good.
[Python is] what I call the fully GPLd equivalent to Java...
Python is not "GPLed"; its license is an OSI-certified BSD-style license.
Also, being "equivalent" to Java is not really Python's goal. Python strives to be considerably higher-level than Java, and incorporates more unorthodox features, such as generators. Python could better be described as a semantic cross between Java and Lisp, with more pleasant syntax than either.
Gates: Jesus, Steve! I mean, I am William G. "SatanSmasher" Gates and everything, but that's pretty extreme. Couldn't you think of a non-violent way to do it?
Ballmer: Uh, I'm drawing a blank here, Bill. Non-violence is not exactly my area of expertise, you know?
Gates: Hm...
Ballmer: Oh! Come to think of it, how about the Steven T. Ballmer International School of Karaoke. That oughta drive away the population at least as fast as a high yield thermonuclear weapon.
Gates: Bingo! You've reminded me why I put up with a CEO I can't distinguish from a lardass gorilla, Steve. Implement it at once!
Ahh, you realise most of the stuff in your comment is either Vaporware or stuff in progress.
Dude, how can you broadcast such untruths? We already have code to implement 85% of the subsystems I mentioned in CVS. The implementation process proceeded with hardly a hitch, thanks to our clairvoyant design white paper.
I guess if you hadn't been so busy working on your home page, you mighta read it.
Slashdot Mirror
I've found that for C++ projects on the low side of medium (say, around 50,000 lines), arranging the compilation so that all of the source code is lumped into a single "unit" accelerates GCC's from-scratch compilation times considerably. Of course, it also uses large amounts of RAM.
.cpp file containing hundreds of .cpp file in the entire project.
For example, direct GCC to compile one top-level
#include "other-source-file-0.cpp"
#include "other-source-file-1.cpp"
#include "other-source-file-....cpp"
#include "other-source-file-673.cpp"
statements, one for each
This forces GCC to compile the whole program as a single unit, so it preprocesses the headers only once, and generates only a single object file.
This achieves approximately the same reductions in compile time as precompiled headers.
Come link time (which can be quite long even for a medium-sized project), instead of needing to combine hundreds of object files, the linker need only deal with one. On x86-Linux with GCC 3.4.x, at least, this accelerates the linking process, plus generates a much smaller and slightly faster binary. I assume that the slight acceleration in the generated code is due to the fact that compiling the entire project as one compilation unit has essentially the same cross-unit optimization benefits as link-time code generation.
Although this technique reduces from-scratch compile times considerably, it's of dubious value in most situations because:
a) Users compiling the software as part of an installation process might find it uncomfortable--or even impossible--to allow the compiler several hundred MB RAM.
b) The developer's changes in a typical edit-compile-test cycle are localized. This technique destroys the possibility of using previously compiled object files for those compilation units whose source code hasn't changed, since there's only one compilation unit for the entire project.
You're quite right that Java's speed is excellent these days (for non-GUI code, at least). I've spent a lot of time recently working with a large system that was first implemented in Java (by highly skilled developers) and then ported to C++ (by greenhorns). The C++ port is only 50-100% faster, which isn't worth the price in developer time that's been wasted on memory leaks and other forms of memory corruption that were never a factor in Java. Besides that, supporting multiple platforms with the C++ version is the #definition of pain.
However, the C++ version uses only about 1/4 or 1/5 as much memory as the Java version, and starts up far more quickly. If a *desktop* application needs to be deployed on older machines, or if the application is so memory-intensive it taxes the limits of today's server hardware, Java still falls flat.
Exercise is almost never bad for a person, and does help one fall asleep, but that's not the issue with sleep apnea.
Sleep apnea causes a person who's already sleeping to stop breathing (or have great difficulty), at which point the brain wakes the body up, and the body resumes breathing. This can happen dozens or more times a night.
So even if the victim is able to fall asleep five minutes after his head hits the pillow, he still can't get rest, because REM is constantly disrupted.
Am I still a virgin if I've only used WiFi?
The problem with .NET or Java as a solution to the library problem is that you end up using your functional language:
.NET, it's also a platform-specific runtime. Don't even bother mentioning Mono; the Microsoft Corporation that exists in the universe I inhabit will never allow Mono to grow into anything more than a token antitrust smoke screen, a perpetually not-quite-ready, not-quite-compatible runner-up. If you expect Microsoft to behave differently, you must not be referring to the corporation that's been systematically raping its competitors by whatever means necessary for the last two decades. The safest elements of .NET--those that have been submitted to ECMA--exclude almost all useful libraries.
1) On a proprietary runtime. In the case of
2) With libraries that were designed for consumption by object-oriented client languages, which robs the would-be functional programmer of much of the value of the functional way. The programming experience degenerates into a sad parody of functional programming that really amounts to object-oriented programming through a functional condom. To paraphrase the famous quote about condoms, "Functional programming with object-oriented libraries is armor against productivity, gossamer against library scarcity."
3) On a runtime that performs 3-10 times worse than a runtime designed for the langauge in question.
Yes, I've been intrigued by OCaml for a long time.
OCaml's major problem is that, like every other functional language available today, the breadth of its standard library and third-party libraries is totally pathetic in comparison to the likes of Java and Python. The same limitation applies to Lisp, Scheme, Haskell, Erlang, etc.
These languages face a Catch-22: until they're more popular, they won't attract enough developers to ameliorate the library situation, yet until they offer better libraries, they won't attract developers. Historically, this barrier has been surmounted in one of two ways: either a deep-pocketed corporation subsidizes library development until the language gains momentum (see Java, C#) or the languages are sufficiently "charming"/"hip" that the library support appears as a result of a grass-roots effort (see Perl, Python).
Is there any realistic prospect that one of the functional languages I mentioned will strike it rich in either of those ways? It doesn't seem likely to me.
The reason you would NOT opt for a single 6800GT is that the performance of a SINGLE 6800 is substantially less than DUAL 6600s.
Bullshit! I certainly haven't seen any benchmarks that support your assertion. Did you even look at the benchmarks I linked to? In most cases, dual 6600 GTs perform slightly worse than a single 6800 GT.
The 6600 cards are pretty reasonably priced, so picking up two of them and getting 180% performance of a single 6600GT AGP is pretty attractive...
No, it isn't. According to reputable benchmarks, dual 6600 GTs ($200 x 2) typically perform slightly worse than a single 6800 GT ($400 x 1).
Why would you accept the undoubtedly higher power consumption of dual 6600 GTs versus a single 6800 GT, when the price is about the same?
Those who can afford a new motherboard (and probably a new CPU) just for the SLI capability won't be stooping to 6600 GTs; they'll opt for something better.
Java is a nearly total failure at desktop applications, and will remain so, because Sun doesn't give a damn about enabling native Java apps to deliver user experiences comparable to those offered by native apps.
Every day I use one of the most successful Java desktop applications (jEdit), and like it very much. So it should tell us something when the author of that application, Slava Pestov, advises programmers to "just give up" on Java for the desktop:
It is clear that Java was never practical for developing real applications, and never will be. Instead of asking how you can revive something that's obviously dead and gotten much more hype than it deserves, you should be asking if there's better technology out there.
If you use Python, Perl, PHP, Ruby, or TCL chances are you use a multitude of libraries that would've been prohibitively laborious to wrap without SWIG.
That's one degree of suppuration. That's business with VD.NET.
The command line C++ compiler was never included in the SDK. The C# compiler and so on were, however.
That's incorrect. The .NET SDK has always included the C++ compiler (installed by default to C:\Program Files\Microsoft Visual Studio .NET 200x\Vc7), but the compiler was the Standard Edition, without an optimizer. If you pass it an optimization switch, the Standard Edition issues a warning to the effect that "The Standard Edition of Microsoft Visual C++ does not include an optimizer.". Naturally, lack of an optimizer makes the Standard Edition almost useless for production code.
This newly released command-line compiler includes a fully functional optimizer. It's the same C++ compiler that underlies VC++ .NET 2003 Professional.
How does a critical vulnerability happen? Seriously. Is there a URL someone can provide or a good description that shows what it takes to make an OS or application with a vulnerability?
Of course there's an infinite number of ways to write a vulnerable program, but the most common is to run afoul of a buffer overflow. A buffer overflow is a relatively simple flaw, but it's an easy mistake to make in C and C++ because those languages give economy of computational resources precedence over every other consideration, including security and stability.
There's an illustrated and fairly concise introduction to buffer overflows at LinuxJournal.
I'm not quite sure what it offers over PostgreSQL.
It's difficult to work with from an administrative level, and not terribly well documented...
I agree that the documentation is mediocre, but firmly disagree that it's hard to administer. The key is: don't. Make a couple of changes in the config file if you need to, configure automatic backups, then forget about it.
What's next? A BSD-is-dead troll getting linked on the front page?
More likely, the next story will be about some guy named Rob Enderle announcing the death of Bluetooth.
In your example, I know with complete certainty that I am creating a new "Type" and assigning it to the variable "varName". This is not the case if it used the syntax of Python. How do you know I am not calling a method called "Type"?
You don't know, and you shouldn't.
Suppose at first you do, in fact, instantiate a new object via the 'Type()' call. Later, during the optimization phase, you discover that in most cases you can return a reference to a pre-existing, pooled object. In Python, you can make that change without breaking client code; not so when object creation is explicitly annotated.
As to whether Type is a method, function, or class constructor, it doesn't matter as long as the returned objects implement the required interface.
Dynamic typing being a Good Thing depends on the context. Dynamic typing tends to move more bugs which could easily be caught at compile time to runtime. This means more testing needs to be done which actually drives up development costs and thus negates any benefit gained from "rapid development".
Indeed, I find that writing test suites saps much of the development speed advantage I gain from using a dynamically typed language.
However, using a soundly designed dynamic language, I can write dynamic-implementation+test-suite in about the same time I could write only static-implementation in, say, Java. But since I have an extensive test suite, I end up with much more reliable code.
You can see official AMD benchmark results of various programs running on Windows XP 32-bit edition vs. Windows XP 64-bit edition beginning on page 36 of this PDF. The results have three columns: time in seconds on WinXP 32-bit w/ 32-bit executable, time in seconds on WinXP 64-bit with 32-bit executable, and time in seconds on WinXP 64-bit with 64-bit executable.
I hope this information has helped.
Thanks for sharing it.
You can see official AMD benchmark results of various programs running on Windows XP 32-bit edition vs. Windows XP 64-bit edition beginning of page 36 of this PDF. The results have three columns: time in seconds on WinXP 32-bit w/ 32-bit executable, time in seconds on WinXP 64-bit with 32-bit executable, and time in seconds on WinXP 64-bit with 64-bit executable.
The results are quite impressive, but I'm not sure we can trust AMD, since obviously they want AMD64 to look good.
NASA declined to pony up $699, prompting SCO to disable their activation key.
[Python is] what I call the fully GPLd equivalent to Java...
Python is not "GPLed"; its license is an OSI-certified BSD-style license.
Also, being "equivalent" to Java is not really Python's goal. Python strives to be considerably higher-level than Java, and incorporates more unorthodox features, such as generators. Python could better be described as a semantic cross between Java and Lisp, with more pleasant syntax than either.
I think you mean GNU/Christ, brother.
Gates: Jesus, Steve! I mean, I am William G. "SatanSmasher" Gates and everything, but that's pretty extreme. Couldn't you think of a non-violent way to do it?
Ballmer: Uh, I'm drawing a blank here, Bill. Non-violence is not exactly my area of expertise, you know?
Gates: Hm...
Ballmer: Oh! Come to think of it, how about the Steven T. Ballmer International School of Karaoke. That oughta drive away the population at least as fast as a high yield thermonuclear weapon.
Gates: Bingo! You've reminded me why I put up with a CEO I can't distinguish from a lardass gorilla, Steve. Implement it at once!
Ahh, you realise most of the stuff in your comment is either Vaporware or stuff in progress.
Dude, how can you broadcast such untruths? We already have code to implement 85% of the subsystems I mentioned in CVS. The implementation process proceeded with hardly a hitch, thanks to our clairvoyant design white paper.
I guess if you hadn't been so busy working on your home page, you mighta read it.