Alan Levy, who knows the literature on transportation infrastructure, makes a convincing case that Musk's hyperloop can't be taken seriously. It
Absurdly underestimates the cost of elevated viaducts (for which we have centuries of engineering experience and reliable cost estimates, which Musk ignored). This alone completely wipes out the supposed cost advantage over high-speed rail, even before you consider the extreme height required of the viaducts (because of the hyperloop's large turning radius) or the unexpected costs that usually arise in implementing brand-new technologies.
Assumes acceleration numbers that are known to be unrealistic for passenger comfort. The thing would be a vomit express.
Has a capacity that is a fraction of high-speed rail's.
...and several other problems.
Levy is not dismissing it "because it sounds a bit wacky." He's dismissing it because a realistic analysis shows that it is wacky.
To pick one data point Singapore is 2.31/1000, and the US is 6.3/1000: the US rate is 273% higher. See here. You seem to be basing your "less than 1%" difference on the fact that all of the developed countries have an infant mortality rate of less than 1%, but this is a ridiculous way to compare statistics for rare events.
You can use compiler builtins for SIMD these days (fairly standardized across Intel, GNU, etc. compilers). (And don't complain about portability if you are using hand-coded SIMD....you have to be using #ifdefs or something anyway.)
Aside from using specialized instructions that are usually accessible from C anyway via builtins, it's not like x86 assembly has much relationship anymore to what actually happens in the hardware; you can't even control the real registers anymore (most CPUs have many more physical registers than are exposed in the instruction set, and rename on the fly).
Besides, most useful optimizations are much higher-level than that (besides the obvious question of algorithm choices, performance is typically dominated by memory access and you are better off focusing on locality than instruction-level efficiency).
All metamaterials are not created equal. A metamaterial is an electromagnetic medium created by a composite of tiny (very subwavelength) constituent structures, put together in such away that longer wavelengths see an "average" material with properties very different from those of the constituents. Usually, the goal is to use resonant effects in the microscopic constituents to make a material that is effectively very different from naturally occuring EM media. But this can be done for many different purposes.
A negative-refractive metamaterial is designed to have an effective "negative" index of refraction, which makes Snell's law (refraction) bend backwards, and can potentially be used for flat-lens near-field imaging, subwavelength imaging (again only in the near field), etcetera. The main practical difficulty here is that the most interesting applications of negative-index materials are in the visible or infrared regime, but negative-index metamaterials rely on metallic constitutents and metals become very lossy at those wavelengths.
Recent "invisibility" cloak proposals are based on the observation that there is a one-to-one mapping between transforming space to "curve around" the object being cloaked and keeping space the same and transforming the materials. So, if you can make materials with certain properties, they could effectively cloak an object by causing all the light rays to curve around the object just as if space were curved. Although this is mathematically quite beautiful, there are many practical obstacles to making this a reality. The proposal is to make the required materials via metamaterials, but these are NOT negative-index metamaterials. The required materials theoretically tend to require some singularities (points where the index blows up or vanishes), and trying to approximate that in practice inevitably involves losses which spoil the cloaking. In general, the bigger the object to be cloaked compared to the wavelength, the smaller the losses have to be, and the narrower the bandwidth is going to be. When you work out the numbers, you see that this is why all the experimental demonstrations of cloaking have only "cloaked" (reduced the scattering crosssection, but not to zero) objects that were a wavelength or two in diameter. Cloaking macroscopic objects at visible wavelengths is a fantasy because the material requirements are insane. The only remotely practical prospects seem to be cloaking objects on the ground (which makes things technically easier because the coordinate transformations are nonsingular) to long-wavelength radiation, e.g. cloaking something against radio waves.
The spin ice state is argued to be well-described by networks of aligned dipoles resembling solenoidal tubesâ"classical, and observable, versions of a Dirac string. Where these tubes end, the resulting defect looks like a magnetic monopole.
They've managed to create the microscopic equivalent of a long skinny magnet or a long bendy solenoid: a set of dipoles aligned end-to-end, which acts just like a string with two "monopoles" at the ends.
While this is an interesting microscopic state of matter, from the "discovering monopoles" point of view it doesn't seem fundamentally different than the macroscopic description of magnet "poles" that has been well understood for over a century (and observed for a lot longer than that). I call hype.
Generating terahertz radiation, especially coherent Terahertz radiation, is hard because the frequency (around 300GHz - 20THz) is too low for conventional solid-state laser technology and too high for conventional electronic antennas. And it is potentially useful for a range of applications such as nondestructive high-resolution imaging (for e.g. materials, medical, and security applications), spectroscopy, or opening up new communications bandwidths. (Google "terahertz applications" and you'll find a lot of links.)
There are a number of terahertz sources that are becoming available, from optical rectification schemes to free-electron lasers, but they have a tendency to be bulky and inefficient, so a lot of researchers are looking for alternative generation schemes.
That being said, I suspect that the terahertz radiation produced by sticky tape is incoherent, which would severely limit its utility in practical applications. (Quite apart from the efficiency, which sounds like it is currently very low.) That doesn't mean that it isn't interesting from a basic science perspective, of course.
First of all, you don't understand the meaning of "non-radiative". Whether or not there is power transfer, it is in the near field, not the far field, and hence it is not radiative. Second, it's not sufficient to have the same resonant frequency; you also have to be impedance-matched. The combination of the two is unlikely in the extreme.
Not that you'd learn it from this non-technical news report, but the energy transfer in WiTricity is non-radiative for this and other reasons. Indiscriminately radiating power not only will interfere with other devices (and violate FCC regulations), but also wastes power by dumping it into the environment, not to mention that people tend to dislike the idea that power is being dumped into their brains. See my other post below.
There are several very different schemes currently being explored for wireless power transfer, with different strengths and weaknesses.
Radiative transfer: send a directed beam of energy from a source to a receiver. The advantage is that this can work over long distances, the disadvantage is that you need to either have fixed locations or some active tracking system to keep pointing at the receiver as it moves around, and you need some kind of automated kill switch to make sure you don't accidentally fry anything that walks between the transmitter and receiver or waste power when the receiver is not there. It looks like PowerCast and PowerBeam fall into this category.
Traditional inductive, non-radiative power transfer. This works well, and does not transfer power when the receiver is absent, but is extremely short-range if you want any kind of efficiency; typically, the device to be charged must be sitting directly on or adjacent to the charger. The Wireless Power Consortium is pursuing this kind of approach.
Resonant, non-radiative power transfer. This relies on the source and receiver being electrical resonators at the same frequency, so that they preferentially transfer energy to one another rather than to other objects in the environment via resonant coupling. This is the approach being pursued by WiTricity, where they additionally rely on resonators that couple primarily via magnetic fields (the electric-field energy is mostly in capacitors inside the devices), which have the advantage that most materials are non-magnetic at these frequencies so the power source dissipates very little energy into extraneous objects (or people). (In contrast, Tesla coils produce strong electric fields external to the device, which interact much more strongly with matter; it's no coincidence that Tesla coils are used as lightning generators.) This operates efficiently at mid-range distances although not as far as radiative transfer (meters at most), does not transfer or dissipate power when the receiver is absent, and is not directional so does not require active "pointing" of the power at the receiver. But it is more complicated than the short-range non-resonant inductive transfer, and requires careful impedance-matching of the source and receiver.
Full disclosure: I know Prof. Soljacic at MIT, who founded WiTricity, although I personally have no financial interest in the company; all of the above information is public and published, however.
It's called copyright law. Yes, it is a pain, but that's not Wikipedia's doing.
The problem is, getting permission just to "use" an image on Wikipedia is not enough. You need to get permission to use it under a license compatible with Wikipedia's goals: it has to permit the image not only to be used, but also to be redistributed, modified, even sold (although you can require redistribution under the same terms allowing free redistribution etc.). Furthermore, you need to get permission from the owner of the copyright - as other posters have noted, this is often the photographer, not the subject of the photo.
I'm sorry you had difficulty contributing to Wikipedia, but don't blame Wikipedia for diligently attempting to follow copyright law, or for your own ignorance thereof.
I haven't seen those benchmarks, and I'm quite skeptical of your claim that ZFS is CPU-bound by 64-bit integer operations. The only times I've heard of where filesystems are CPU-bound are when they are using compression and/or encryption, and both of those problems can operate on narrower integers (possibly in 128-bit vectors ala SSE).
As for simulations, the overwhelming majority of scientific simulations rely on floating-point arithmetic.
You've got to be joking. Filesystem operations use 64-bit integer calculations, sure, but that is not even close to their being performance limiting. Do you realize how many orders of magnitude slower the disk is than the CPU?
64-bit integer calculations are rarely if ever a performance bottleneck (not including address calculations). And in applications where 32-bit integers were already wide enough for you, there is no benefit to going 64-bit integers (and it is actually slower because of increased cache pressure).
Name one real-world application in which 64-bit integer calculations (not including address calculations) are a significant performance bottleneck, and 32-bit integers are too narrow.
In 32-bit mode, PowerPC and SPARC registers are 32-bit (on 64-bit systems they're just sign-extended when running 32-bit code).
I can't believe how much total nonsense is being propagated on this thread. To quote the IBM PowerPC Instruction Set Architecture manual:
Implementations of this architecture provide 32 floating-point registers (FPRs). [...] Each FPR contains 64 bits that support the floating-point double format.
So, you have it completely backwards: there are no 32-bit single-precision registers on PowerPC, whether in 32-bit or 64-bit mode. It only has 64-bit double-precision registers. Single-precision floating-point operations (not including AltiVec) are done with the double-precision hardware, and are rounded to single-precision when they are spilled. So, storing a 64-bit floating-point value does not "halve" the number of available registers: it uses exactly the same (double precision) registers as for single-precision math.
The situation is very similar on x86: single and double precision use exactly the same hardware registers (which are actually 80-bit extended-precision registers on 32-bit x86 machines); going from 32-bit to 64-bit fp types does not halve the number of physical registers available. (And thanks to hardware register renaming, the instruction set's nominal limitation on the number of registers is not really a practical limitation; the hardware lets you exploit the much larger set of real physical registers.)
Judging by this thread, the "64-bit CPUs can process data twice as quickly as 32-bit CPUs" hooey has been circulating for so long that people have begun to invent works of fiction to justifiy it in their minds.
What the document you are referring to is about is the support for Intel SIMD extensions on AMD. Originally, AMD supported their own 64-bit SIMD operations called 3DNow! which could do two single-precision fp operations at once. Intel, on the other hand, had 128-bit SIMD instructions called SSE which could do four single-precision fp operations at once. Then AMD added support for SSE to their processors, but essentially emulated it with 3DNow! so that one SSE instruction would really use two 3DNow! instructions and take two cycles. Intel also had SSE2 instructions that could do 2 double-precision fp instructions in a cycle, which AMD emulated by doing it in 2 cycles with their ordinary fp unit. The document you are linking describes the fact that AMD eventually dropped 3DNow! and added true hardware support for SSE/SSE2 so that they could do all four/two fp operations in a cycle.
This happened to coincide with their switch to amd64, since they took advantage of the change in instruction set to drop their old 3DNow! instructions. But it has nothing to do with "64-bit" per se. Moreover, on Intel 32-bit CPUs, the 128-bit SSE instructions did execute in a cycle because they were supported in hardware. And even the old 32-bit AMD cpus did 64-bit floating-point and 3DNow! operations in a cycle.
You really don't get it, do you. Even on a 32-bit processor like x86, there are programmer-visible (IN THE INSTRUCTION SET) 64-bit and 128-bit registers. The 64-bit registers are the double-precision floating-point registers (and in fact these are 80-bit extended-precision registers on x86), and the 128-bit registers are from SSE and the other Intel SIMD extensions. The terms 32-bit and 64-bit refer only to the size of addresses, not to all registers or anything else.
The rest of your post follows from your total ignorance, and I will ignore it.
64bit chunks of computations instead of 32bit chunks. So the data being 'computed' is in native 64bit chunks - and in theory could be twice as fast in an optimal pass.
Yes, you've managed to paraphrase the usual bullshit that you've been brainwashed with quite well. Here's a hint: the 32-bit x86 processors had 64-bit (and 128-bit) registers already.
2) 64bit CPU features - more registers, other AMD64/EMT64 features
Nothing to do with 64 bits, and certainly not a simple "factor of 2" in "data processing rates" or "instructions per clock cycle". As I said, newer architectures can certainly be faster for reasons that have nothing to do with 64 bit addressing, and which have nothing to do with hype about "factors of 2" gained by "going from 32 bits to 64 bits" (which is obviously twice as good, right?)
3) Combined memory read writes, for example in Vista x64 when a 32bit application is reading or writing to RAM the OS can often combine two 32bit read/writes into ONE 64bit read/write, thus speeding up RAM access.
See point (1): the 32-bit processors could do this already.
You have a 64-bit data path even on old 32-bit processors: it's called double precision. And there are 128-bit data paths, too, on any 32- bit Intel x86 CPU for the past 10 years: MMX and SSE*. The width of the SSE registers (the single-precision SIMD extensions you are referring to) did not increase with x86_64/amd64/em64t.
The width of the widest data register has absolutely nothing to do with the size of the address space.
64-bit computing [...] enables computers to process twice the number of instructions per clock cycle, which can dramatically speed up numeric calculations and other tasks.
Haven't people learned by now that this is total BS? 64-bit addressing is independent of instructions per cycle, bus width, or anything like that. (Of course, newer 64-bit systems may be happen to be faster for other, unrelated reasons.) The old "64-bit is twice as fast as 32-bit" is a line of hooey that has been sold to the public for years now (I recall it gaining prominence when Intel started promoting its Itanium plans), but I thought it was finally dying out.
It's quite hard to keep C++ libraries ABI compatible across releases, because of fragile base class problems as well as ABI changes with new releases of C++ compilers (grrr).
If your ABI changes, then your.so version number has to reflect this and software needs to be recompiled. My point was that, contrary to Tweenk's claims, if the ABI of a new library version is backwards compatible, the Unix/Linux.so versioning scheme can reflect this and software doesn't need to be recompiled.
With C libraries, it's usually possible to maintain ABI compatibility even when adding new features. Unfortunately, proper.so versioning cannot fix the many ways in which C++ sucks.
Slashdot Mirror
Levy is not dismissing it "because it sounds a bit wacky." He's dismissing it because a realistic analysis shows that it is wacky.
To pick one data point Singapore is 2.31/1000, and the US is 6.3/1000: the US rate is 273% higher. See here. You seem to be basing your "less than 1%" difference on the fact that all of the developed countries have an infant mortality rate of less than 1%, but this is a ridiculous way to compare statistics for rare events.
You can use compiler builtins for SIMD these days (fairly standardized across Intel, GNU, etc. compilers). (And don't complain about portability if you are using hand-coded SIMD....you have to be using #ifdefs or something anyway.)
Aside from using specialized instructions that are usually accessible from C anyway via builtins, it's not like x86 assembly has much relationship anymore to what actually happens in the hardware; you can't even control the real registers anymore (most CPUs have many more physical registers than are exposed in the instruction set, and rename on the fly).
Besides, most useful optimizations are much higher-level than that (besides the obvious question of algorithm choices, performance is typically dominated by memory access and you are better off focusing on locality than instruction-level efficiency).
GNU, Intel, etcetera have compiler builtins for SIMD instructions that are usable directly from C.
All metamaterials are not created equal. A metamaterial is an electromagnetic medium created by a composite of tiny (very subwavelength) constituent structures, put together in such away that longer wavelengths see an "average" material with properties very different from those of the constituents. Usually, the goal is to use resonant effects in the microscopic constituents to make a material that is effectively very different from naturally occuring EM media. But this can be done for many different purposes.
A negative-refractive metamaterial is designed to have an effective "negative" index of refraction, which makes Snell's law (refraction) bend backwards, and can potentially be used for flat-lens near-field imaging, subwavelength imaging (again only in the near field), etcetera. The main practical difficulty here is that the most interesting applications of negative-index materials are in the visible or infrared regime, but negative-index metamaterials rely on metallic constitutents and metals become very lossy at those wavelengths.
Recent "invisibility" cloak proposals are based on the observation that there is a one-to-one mapping between transforming space to "curve around" the object being cloaked and keeping space the same and transforming the materials. So, if you can make materials with certain properties, they could effectively cloak an object by causing all the light rays to curve around the object just as if space were curved. Although this is mathematically quite beautiful, there are many practical obstacles to making this a reality. The proposal is to make the required materials via metamaterials, but these are NOT negative-index metamaterials. The required materials theoretically tend to require some singularities (points where the index blows up or vanishes), and trying to approximate that in practice inevitably involves losses which spoil the cloaking. In general, the bigger the object to be cloaked compared to the wavelength, the smaller the losses have to be, and the narrower the bandwidth is going to be. When you work out the numbers, you see that this is why all the experimental demonstrations of cloaking have only "cloaked" (reduced the scattering crosssection, but not to zero) objects that were a wavelength or two in diameter. Cloaking macroscopic objects at visible wavelengths is a fantasy because the material requirements are insane. The only remotely practical prospects seem to be cloaking objects on the ground (which makes things technically easier because the coordinate transformations are nonsingular) to long-wavelength radiation, e.g. cloaking something against radio waves.
From one of the articles:
They've managed to create the microscopic equivalent of a long skinny magnet or a long bendy solenoid: a set of dipoles aligned end-to-end, which acts just like a string with two "monopoles" at the ends.
While this is an interesting microscopic state of matter, from the "discovering monopoles" point of view it doesn't seem fundamentally different than the macroscopic description of magnet "poles" that has been well understood for over a century (and observed for a lot longer than that). I call hype.
Terahertz sources don't require particle accelerators. See my post above ("Terahertz generation is an interesting problem".)
Generating terahertz radiation, especially coherent Terahertz radiation, is hard because the frequency (around 300GHz - 20THz) is too low for conventional solid-state laser technology and too high for conventional electronic antennas. And it is potentially useful for a range of applications such as nondestructive high-resolution imaging (for e.g. materials, medical, and security applications), spectroscopy, or opening up new communications bandwidths. (Google "terahertz applications" and you'll find a lot of links.)
There are a number of terahertz sources that are becoming available, from optical rectification schemes to free-electron lasers, but they have a tendency to be bulky and inefficient, so a lot of researchers are looking for alternative generation schemes.
That being said, I suspect that the terahertz radiation produced by sticky tape is incoherent, which would severely limit its utility in practical applications. (Quite apart from the efficiency, which sounds like it is currently very low.) That doesn't mean that it isn't interesting from a basic science perspective, of course.
First of all, you don't understand the meaning of "non-radiative". Whether or not there is power transfer, it is in the near field, not the far field, and hence it is not radiative. Second, it's not sufficient to have the same resonant frequency; you also have to be impedance-matched. The combination of the two is unlikely in the extreme.
Not that you'd learn it from this non-technical news report, but the energy transfer in WiTricity is non-radiative for this and other reasons. Indiscriminately radiating power not only will interfere with other devices (and violate FCC regulations), but also wastes power by dumping it into the environment, not to mention that people tend to dislike the idea that power is being dumped into their brains. See my other post below.
Full disclosure: I know Prof. Soljacic at MIT, who founded WiTricity, although I personally have no financial interest in the company; all of the above information is public and published, however.
It's called copyright law. Yes, it is a pain, but that's not Wikipedia's doing.
The problem is, getting permission just to "use" an image on Wikipedia is not enough. You need to get permission to use it under a license compatible with Wikipedia's goals: it has to permit the image not only to be used, but also to be redistributed, modified, even sold (although you can require redistribution under the same terms allowing free redistribution etc.). Furthermore, you need to get permission from the owner of the copyright - as other posters have noted, this is often the photographer, not the subject of the photo.
I'm sorry you had difficulty contributing to Wikipedia, but don't blame Wikipedia for diligently attempting to follow copyright law, or for your own ignorance thereof.
I was thinking of the (thinly disguised) flat file system that shipped on the original Macintosh in 1984.
As pointed out in this review:
You can't organize PDFs into directories on the Kindle, which makes accessing a large number of PDFs a serious problem. It's like 1984.
(The lack of PDF annotation capability is also a headache.)
I haven't seen those benchmarks, and I'm quite skeptical of your claim that ZFS is CPU-bound by 64-bit integer operations. The only times I've heard of where filesystems are CPU-bound are when they are using compression and/or encryption, and both of those problems can operate on narrower integers (possibly in 128-bit vectors ala SSE).
As for simulations, the overwhelming majority of scientific simulations rely on floating-point arithmetic.
You've got to be joking. Filesystem operations use 64-bit integer calculations, sure, but that is not even close to their being performance limiting. Do you realize how many orders of magnitude slower the disk is than the CPU?
64-bit integer calculations are rarely if ever a performance bottleneck (not including address calculations). And in applications where 32-bit integers were already wide enough for you, there is no benefit to going 64-bit integers (and it is actually slower because of increased cache pressure).
Name one real-world application in which 64-bit integer calculations (not including address calculations) are a significant performance bottleneck, and 32-bit integers are too narrow.
I can't believe how much total nonsense is being propagated on this thread. To quote the IBM PowerPC Instruction Set Architecture manual:
So, you have it completely backwards: there are no 32-bit single-precision registers on PowerPC, whether in 32-bit or 64-bit mode. It only has 64-bit double-precision registers. Single-precision floating-point operations (not including AltiVec) are done with the double-precision hardware, and are rounded to single-precision when they are spilled. So, storing a 64-bit floating-point value does not "halve" the number of available registers: it uses exactly the same (double precision) registers as for single-precision math.
The situation is very similar on x86: single and double precision use exactly the same hardware registers (which are actually 80-bit extended-precision registers on 32-bit x86 machines); going from 32-bit to 64-bit fp types does not halve the number of physical registers available. (And thanks to hardware register renaming, the instruction set's nominal limitation on the number of registers is not really a practical limitation; the hardware lets you exploit the much larger set of real physical registers.)
Judging by this thread, the "64-bit CPUs can process data twice as quickly as 32-bit CPUs" hooey has been circulating for so long that people have begun to invent works of fiction to justifiy it in their minds.
Sorry, you're still wrong.
What the document you are referring to is about is the support for Intel SIMD extensions on AMD. Originally, AMD supported their own 64-bit SIMD operations called 3DNow! which could do two single-precision fp operations at once. Intel, on the other hand, had 128-bit SIMD instructions called SSE which could do four single-precision fp operations at once. Then AMD added support for SSE to their processors, but essentially emulated it with 3DNow! so that one SSE instruction would really use two 3DNow! instructions and take two cycles. Intel also had SSE2 instructions that could do 2 double-precision fp instructions in a cycle, which AMD emulated by doing it in 2 cycles with their ordinary fp unit. The document you are linking describes the fact that AMD eventually dropped 3DNow! and added true hardware support for SSE/SSE2 so that they could do all four/two fp operations in a cycle.
This happened to coincide with their switch to amd64, since they took advantage of the change in instruction set to drop their old 3DNow! instructions. But it has nothing to do with "64-bit" per se. Moreover, on Intel 32-bit CPUs, the 128-bit SSE instructions did execute in a cycle because they were supported in hardware. And even the old 32-bit AMD cpus did 64-bit floating-point and 3DNow! operations in a cycle.
You really don't get it, do you. Even on a 32-bit processor like x86, there are programmer-visible (IN THE INSTRUCTION SET) 64-bit and 128-bit registers. The 64-bit registers are the double-precision floating-point registers (and in fact these are 80-bit extended-precision registers on x86), and the 128-bit registers are from SSE and the other Intel SIMD extensions. The terms 32-bit and 64-bit refer only to the size of addresses , not to all registers or anything else.
The rest of your post follows from your total ignorance, and I will ignore it.
Yes, you've managed to paraphrase the usual bullshit that you've been brainwashed with quite well. Here's a hint: the 32-bit x86 processors had 64-bit (and 128-bit) registers already.
Nothing to do with 64 bits, and certainly not a simple "factor of 2" in "data processing rates" or "instructions per clock cycle". As I said, newer architectures can certainly be faster for reasons that have nothing to do with 64 bit addressing, and which have nothing to do with hype about "factors of 2" gained by "going from 32 bits to 64 bits" (which is obviously twice as good, right?)
See point (1): the 32-bit processors could do this already.
Bullshit.
You have a 64-bit data path even on old 32-bit processors: it's called double precision. And there are 128-bit data paths, too, on any 32- bit Intel x86 CPU for the past 10 years: MMX and SSE*. The width of the SSE registers (the single-precision SIMD extensions you are referring to) did not increase with x86_64/amd64/em64t.
The width of the widest data register has absolutely nothing to do with the size of the address space.
Haven't people learned by now that this is total BS? 64-bit addressing is independent of instructions per cycle, bus width, or anything like that. (Of course, newer 64-bit systems may be happen to be faster for other, unrelated reasons.) The old "64-bit is twice as fast as 32-bit" is a line of hooey that has been sold to the public for years now (I recall it gaining prominence when Intel started promoting its Itanium plans), but I thought it was finally dying out.
It's quite hard to keep C++ libraries ABI compatible across releases, because of fragile base class problems as well as ABI changes with new releases of C++ compilers (grrr).
If your ABI changes, then your .so version number has to reflect this and software needs to be recompiled. My point was that, contrary to Tweenk's claims, if the ABI of a new library version is backwards compatible, the Unix/Linux .so versioning scheme can reflect this and software doesn't need to be recompiled.
With C libraries, it's usually possible to maintain ABI compatibility even when adding new features. Unfortunately, proper .so versioning cannot fix the many ways in which C++ sucks.