Taking n processors and making them each m-way multi-threading gives you m x n threads, not m^n (or n^m) threads. So the use of the word exponentially is totally false. Probably written by someone who would use "Quantum Leap" to describe a very large advance rather than a very small one.
Also the licensing issue is one that comes up on multi-threaded architectures because the threads look to the OS (and the licensing software) as multiple cpus. I expect this has been fixed but its was certainly a problem at first. Its more a marketing issue than a technical one.
So there's nothing new here. The main point of interest would be how many way can you actually go out and buy and how much bang you get for your buck on your app of interest. That's not a trivial consideration but its not earth-shaking.
The other point of interest is how the cache scales. If the shared cache scales as number of cores then you get some diversity and sharing that yields performance gains over multiple CPU systems (with no shared cache).
If the cores go up but the cache does not then you are generally better off with separate CPUs - although of course its not hard to produce synthetic examples where the opposite is true. Finding a real app where multicore with fixed cache is faster will be harder, though probably not impossible (something that pushes a wave front might do it).
It is interesting to contrast the SGI/Cray NUMA approach. With multi-core the memory bandwidth is fixed but so is memory access latency. With NUMA bandwidth also scales with number of processors but you pay a latency price for non-local memory access.
(SGI's machines are actually multi-processors per memory system so the above is a simplification of the actual case)
I find it hard to believe that highway ever runs. Maybe at 2 in the morning. When I've been on it, it occasionally managed to raise a crawl.
As to whether that makes it more or less pleasant to live next to is debatable. I've always tended to think congestion causes more rather than less pollution.
Lets see - pollution caused by a vehicle is roughly proportional to P = A + Bv^2 per second.
Let the number of vehicles passing a point be N per second. Distance between vehicles is d=v/N (velocity in metres/second)
Pollution per metre of freeway is D=P/d = (A+Bv^2)N/v = NA/v + NBv.
dD/dv = -NA/v^2+NB.
So for slope 0. A/v^2=B. V=sqrt(A/B)
And that's a point of upward inflection (ie, a minimum). I have no idea of the values of A and B but at least this shows there is a velocity>0 that minimizes pollution.
The article correctly states that code coverage by itself is not a good indicator of testing quality but then gives a specious reason.
The given reason is that you have to check the result or its no use, but that applies to any form of testing.
The real problem with using code coverage as an indicator is that a given line of code can be executed with many states and what you need is coverage of the cartesian product of statements and states.
A good example is an optimization in a compiler where you may spend many lines of code checking if it is possible and only 1 or 2 actually doing the optimization. So if you never do the optimization you could easily have close to 100% code coverage but you have 0% testing of the optimization.
So as a measurement it is falacious, as there is no correlation between percentage tested and percentage covered for less than 100% coverage but you can see that you can even have 100% code coverage and still miss bugs from the following statement:
if (size > limit) size = limit - 1;
which fails if size == limit (you intended to write >=) - i.e. there is one value of the state that fails.
A lunch box computer has an inbuilt screen, a detachable keyboard that clips onto the front of the box when not in use, and is capable of accepting regular boards and disks. The first lunchbox computer was the HP Pisces back around 1985 (it ran Unix too!)
Its a very useful form factor that nobody seems to make anymore since it gives you portability with high performance and expandibility.
There's been lots of comments about not comparing like with like and the question of finding problems by code review or test versus actual failures.
But one could also look at the trend lines. That will allow to estimate what percentage of vulnerabilities have been fixed for each platform. Then one could compare those two numbers. That will somewhat reduce the effect of not comparing like with like, although you could get an artifact due to Microsoft bundling increasing numbers of patches in order to meet a patch release schedule (I don't know what their policy on bundling is)
You don't get a slingshot effect from the black hole at the centre of the galaxy in the same way as you do from a planet because the black hole is at rest. The presence of a companion was crucial.
Its more like a satelite performing a rocket burn near the sun in order to gain velocity. Because the exhaust comes out moving more slowly (relative the the far away observer) than it would if the satellite was in higher orbit, the satelite gets much more boost.
In the case of a binary system and the black hole, I expcect what happens is the tidal forces break appart the binary system. The component that was travelling in the direction of motion (relative to the black hole) gets ejected with increased velocity while the unfortunate companion gets swallowed up - or goes into a much tighter orbit.
I wonder how much boost you get from the black hole at the centre of our galaxy as a result of frame dragging? Does frame dragging in fact produce a boost? (I would expect so) Do we have any estimates of the effect for the galactic centre?
There's two problems with this article. First its not a new idea, second it won't work as described.
The old idea was to heat a mass of frozen carbon dioxide with a ground based laser and eject the gas through a nozzle. Don't remember who invented this but Jerry Pournelle used it in one of his novels.
A second related old idea is the idea of propelling aircraft with microwaves from space based power stations.
The more serious problem is it won't work.
Isp is Isp. That's what controls your fuel to payload ratio. Note that this system is primarily NOT working as a solar sail - the reaction mass is coming off the sail itself, not incident upon it. You only win if you can increase the Isp.
Lets assume you can't heat the sale to several thousand degrees. Carbon fibre won't stand up to that and you have the additional interesting diffculty of keeping one side of the sail very hot and the other side cool - so the sail is not going to be thin and light.
So we are knocking off molecules as a quantum process. The energy of each ejected molecule is one microwave photon's energy. So its not very hot. If we work at the top of the microwave range (300Ghz) each photon is 2E-22J. If we are ejecting atomic hydrogen (best case), and if my calculations are correct (hah!) the hydrogen comes off at 550 metres/second. So the Isp is roughly 60, which is lousy.
Now using a sail to focus ground based microwaves on an ion engine - that could be worth doing. You heat the engine and then inject hydrogen into it.
Its not that simple. Network effects can either kill you or make life much simpler. So your per-user costs change.
Plus some part of a support persons cost is a capital cost (they have to learn how to do it) and some part is marginal (they have to do it). If the capital cost is higher on Windows, you may get more economy of scale. However, a 250 user company is probably big enough that support economies of scale are not going to make big changes in relative costs.
In the past Linux (or Unix in general) would have been a clear winner here. Windows has lifted its game but as I have not been involved in Windows admin for years, I don't know to what extent.
This company has spent a bucket of bucks to produce this system.
At the same time, the licensor clearly intended that this sort of use not be permitted by the license.
So either the licensee failed to read the license correctly, or the licensor failed to write a license agreement that met their objectives.
If it turns out to be the licensor who goofed, I wonder if the system then becomes illegal because it is a restraint of trade that does not meet any valid business purpose?
Except that the intro says that they do put that in the EULA. Even if they did not do that, it would be interesting to hear from some legally savvy readers what sort of a theory they could produce that would have a leg to stand on in court.
It would be like Ford suing Honda (to pick two names at random) because Honda dealers were allowing Ford owner's to trade in their cars on a new Honda)
CRAM = Card Random Access Memory. It was a machine full of magnetic cards, each a bit bigger than a playing card, with a vacuum feed mechanism to load them (if you were lucky) to a drum for reading and writing.
Used to be a feature of early NCR (National Cash Register, also known as No Computers Really) machines before disks were readily available.
Its keys features were
a/ It drowned out small jet aircraft taking off from the same room.
b/ The cards would fail to feed frequently, making sure that the days did not drag for your system operators when they did not have forms and VFU loops to load on the printers.
c/ The entire cabinet, which was about the size of a vending machine, could hold megabytes of data.
d/ It gave access times measured in seconds, so the fact that your computer was blazingly slow did not matter.
I prefer "He who rides the tiger can never dismount".
I think you can be pretty sure that if Amazon thought they could get a patent on this they would have been there first. The fact that its only just been issued suggests they had plenty of time to do that.
So I will be surprised if this suit is not thrown out pretty quickly.
What we need is to change the law so the loser pays costs, like on the rest of the planet. That will get rid of most frivolous lawsuits of all kinds real fast and would remove the financial incentive for applying for dubious patents.
Fixing the patent system would certainly be a good thing too, but its not the root cause of these problems.
The interesting thing is that it costs 1/3 to 1/4 of the cost to upgrade between versions of Windows that it costs to completely convert to Linux.
Which means that after 3 or 4 releases of Windows you break even by cutting across to Linux!
Of course you still will want to upgrade your Linux every so often, and that will incur a cost, but, unlike Windows, where upgrading one machine often means upgrading every machine, you don't have to upgrade every machine at once when using Linux.
I was puzzled by his numbers on vulnerabilities. He said that "Windows had fixed 120 vulnerabilities in a 12 month period" which implies an arrival rate of 10 a month but later on he gives a much lower arrival rate.
Perhaps the answer is there was a huge backlog.
I also doubt that his comparitive vulnerability reporting rates have any validity. I doubt he included MS vulnerabilities found internally, whereas the Linux numbers will include all vulnerabilities, and the application base over which the Linux numbers are reported is almost certainly significantly larger.
Slashdot Mirror
Yes, but the advantage of digital cable is you watch it so much more. It takes at least five times as long to discover there's nothing on.
What's Renfair? Is there also a StimpyFair?
Also the licensing issue is one that comes up on multi-threaded architectures because the threads look to the OS (and the licensing software) as multiple cpus. I expect this has been fixed but its was certainly a problem at first. Its more a marketing issue than a technical one.
So there's nothing new here. The main point of interest would be how many way can you actually go out and buy and how much bang you get for your buck on your app of interest. That's not a trivial consideration but its not earth-shaking.
The other point of interest is how the cache scales. If the shared cache scales as number of cores then you get some diversity and sharing that yields performance gains over multiple CPU systems (with no shared cache).
If the cores go up but the cache does not then you are generally better off with separate CPUs - although of course its not hard to produce synthetic examples where the opposite is true. Finding a real app where multicore with fixed cache is faster will be harder, though probably not impossible (something that pushes a wave front might do it).
It is interesting to contrast the SGI/Cray NUMA approach. With multi-core the memory bandwidth is fixed but so is memory access latency. With NUMA bandwidth also scales with number of processors but you pay a latency price for non-local memory access.
(SGI's machines are actually multi-processors per memory system so the above is a simplification of the actual case)
I find it hard to believe that highway ever runs. Maybe at 2 in the morning. When I've been on it, it occasionally managed to raise a crawl.
As to whether that makes it more or less pleasant to live next to is debatable. I've always tended to think congestion causes more rather than less pollution.
Lets see - pollution caused by a vehicle is roughly proportional to P = A + Bv^2 per second.
Let the number of vehicles passing a point be N per second. Distance between vehicles is d=v/N (velocity in metres/second)
Pollution per metre of freeway is D=P/d = (A+Bv^2)N/v = NA/v + NBv.
dD/dv = -NA/v^2+NB.
So for slope 0. A/v^2=B. V=sqrt(A/B)
And that's a point of upward inflection (ie, a minimum). I have no idea of the values of A and B but at least this shows there is a velocity>0 that minimizes pollution.
The given reason is that you have to check the result or its no use, but that applies to any form of testing.
The real problem with using code coverage as an indicator is that a given line of code can be executed with many states and what you need is coverage of the cartesian product of statements and states.
A good example is an optimization in a compiler where you may spend many lines of code checking if it is possible and only 1 or 2 actually doing the optimization. So if you never do the optimization you could easily have close to 100% code coverage but you have 0% testing of the optimization.
So as a measurement it is falacious, as there is no correlation between percentage tested and percentage covered for less than 100% coverage but you can see that you can even have 100% code coverage and still miss bugs from the following statement:
if (size > limit) size = limit - 1;
which fails if size == limit (you intended to write >=) - i.e. there is one value of the state that fails.
Its a very useful form factor that nobody seems to make anymore since it gives you portability with high performance and expandibility.
Yes, but mine's running Windows, so its a non-deterministic Finite State Machine.
But one could also look at the trend lines. That will allow to estimate what percentage of vulnerabilities have been fixed for each platform. Then one could compare those two numbers. That will somewhat reduce the effect of not comparing like with like, although you could get an artifact due to Microsoft bundling increasing numbers of patches in order to meet a patch release schedule (I don't know what their policy on bundling is)
On the other hand, I guess it wouldn't have a problem concealing a battery from the stewards.
Its more like a satelite performing a rocket burn near the sun in order to gain velocity. Because the exhaust comes out moving more slowly (relative the the far away observer) than it would if the satellite was in higher orbit, the satelite gets much more boost.
In the case of a binary system and the black hole, I expcect what happens is the tidal forces break appart the binary system. The component that was travelling in the direction of motion (relative to the black hole) gets ejected with increased velocity while the unfortunate companion gets swallowed up - or goes into a much tighter orbit.
I wonder how much boost you get from the black hole at the centre of our galaxy as a result of frame dragging? Does frame dragging in fact produce a boost? (I would expect so) Do we have any estimates of the effect for the galactic centre?
I thought the Ondes-Martenot was the first but the therimin is earlier. Even it is not the earliest though.
(I still think the Ondes-Martenot is one of the coolest early electronic instruments. )
Yeah - but the difference is when you smash your thumb with a hammer, you generally find out about during QA.
The old idea was to heat a mass of frozen carbon dioxide with a ground based laser and eject the gas through a nozzle. Don't remember who invented this but Jerry Pournelle used it in one of his novels.
A second related old idea is the idea of propelling aircraft with microwaves from space based power stations.
The more serious problem is it won't work.
Isp is Isp. That's what controls your fuel to payload ratio. Note that this system is primarily NOT working as a solar sail - the reaction mass is coming off the sail itself, not incident upon it. You only win if you can increase the Isp.
Lets assume you can't heat the sale to several thousand degrees. Carbon fibre won't stand up to that and you have the additional interesting diffculty of keeping one side of the sail very hot and the other side cool - so the sail is not going to be thin and light.
So we are knocking off molecules as a quantum process. The energy of each ejected molecule is one microwave photon's energy. So its not very hot. If we work at the top of the microwave range (300Ghz) each photon is 2E-22J. If we are ejecting atomic hydrogen (best case), and if my calculations are correct (hah!) the hydrogen comes off at 550 metres/second. So the Isp is roughly 60, which is lousy.
Now using a sail to focus ground based microwaves on an ion engine - that could be worth doing. You heat the engine and then inject hydrogen into it.
Plus some part of a support persons cost is a capital cost (they have to learn how to do it) and some part is marginal (they have to do it). If the capital cost is higher on Windows, you may get more economy of scale. However, a 250 user company is probably big enough that support economies of scale are not going to make big changes in relative costs.
In the past Linux (or Unix in general) would have been a clear winner here. Windows has lifted its game but as I have not been involved in Windows admin for years, I don't know to what extent.
At the same time, the licensor clearly intended that this sort of use not be permitted by the license.
So either the licensee failed to read the license correctly, or the licensor failed to write a license agreement that met their objectives.
If it turns out to be the licensor who goofed, I wonder if the system then becomes illegal because it is a restraint of trade that does not meet any valid business purpose?
In any case, this will be a case worth watching.
I'm calling my broker and stocking up on tin foil futures.
It would be like Ford suing Honda (to pick two names at random) because Honda dealers were allowing Ford owner's to trade in their cars on a new Honda)
The real reason for these hot summers is extra heat being generated by internet sites from being slash-dotted.
Yes - they do it to get exercise.
Used to be a feature of early NCR (National Cash Register, also known as No Computers Really) machines before disks were readily available.
Its keys features were
a/ It drowned out small jet aircraft taking off from the same room.
b/ The cards would fail to feed frequently, making sure that the days did not drag for your system operators when they did not have forms and VFU loops to load on the printers.
c/ The entire cabinet, which was about the size of a vending machine, could hold megabytes of data.
d/ It gave access times measured in seconds, so the fact that your computer was blazingly slow did not matter.
The first thing they should have spent some money on was a server that couldn't be slash dotted!
I think you can be pretty sure that if Amazon thought they could get a patent on this they would have been there first. The fact that its only just been issued suggests they had plenty of time to do that.
So I will be surprised if this suit is not thrown out pretty quickly.
What we need is to change the law so the loser pays costs, like on the rest of the planet. That will get rid of most frivolous lawsuits of all kinds real fast and would remove the financial incentive for applying for dubious patents.
Fixing the patent system would certainly be a good thing too, but its not the root cause of these problems.
Which means that after 3 or 4 releases of Windows you break even by cutting across to Linux!
Of course you still will want to upgrade your Linux every so often, and that will incur a cost, but, unlike Windows, where upgrading one machine often means upgrading every machine, you don't have to upgrade every machine at once when using Linux.
I was puzzled by his numbers on vulnerabilities. He said that "Windows had fixed 120 vulnerabilities in a 12 month period" which implies an arrival rate of 10 a month but later on he gives a much lower arrival rate.
Perhaps the answer is there was a huge backlog.
I also doubt that his comparitive vulnerability reporting rates have any validity. I doubt he included MS vulnerabilities found internally, whereas the Linux numbers will include all vulnerabilities, and the application base over which the Linux numbers are reported is almost certainly significantly larger.
No - its the one that prohibits programming ICBMs in C shell.