LLVM bitcode contains (and needs) the datalayout of the target. This datalayout means such things as default data sizes and alignment rules. Pointer size is different for 32- and 64-bit architectures, so same LLVM bitcode cannot work in both 32- and 64-bit mode.
So, bitcode alone cannot explain portability to 64-bit.
It might be that the development tools have compiled separate bitcode files for 32-and 64-bit architectures.
1) Shouting "bigger pays of we will go to strike" 2) Shouting "you may not do any improvements for more flexible work contracts, or we will go to strike".
Absolutely no understanding that the world economy has changed since 1970's, and absolutely no understanding od thet fact that finland has been belonginf to EU for over 20 years should make things very different than things were in 1970s.
Also absolutely no understanding of the fact that Nokia was holding Finnish economy high and now when Nokia is no longer making mobile phones, Finnish economy is doing much worse and they cannot require so high wages anymore.
In Finland the worker unions are way too strong, they have some rights (or actually wrongs) worker unions in other countries do not have:
1) The worker unions also decide how much is paid to employers that are not members of the union. 2) You get tax rebates for belonging to worker union. 3) In order to get better unemployment benefits you HAVE to belong to some unemployment fund, even though only about 1% of the unemployment compensation money comes from the unemployment fund, 99% comes directly from the goverment. Most of these unemployment funds are ran by the worker unions. (fortunately there is also one private on, "YTK", "common unemployment fund", but many people do not know it exists)
Falcon 9 and the space shuttle are the only rockets whose engines have survived the launch so that they could have been inspected. And similar cracks have been found on shuttle engines too. Many other rocket engines very probbly have generated similar cracks during their burn, but those have not been inspected because the engines have gone to the bottom of the ocean.
There have been 28 launches of falcon. During those 28 launches, 279 Merlin 1-series engines have been used, with only 1 major engine problem. And even in that case, the rocket delivered the primary payload to the desired orbit; Each falcon 9 has 10 engines and only on of those 10 engines is critical whose failure leads to mission failure.
So, until now, the engines have had 99.64% reliability, and due the engine redundancy, only 10% of engine failures means mission failure on most launches(upper stage engine may not fail), meaning mission failure probability of 0.04% due failing engine if the engines keep working equally well in the future than they previously have been working.
No, the this turbine thing is not a big problem. Bigger problems are elsewhere, and spaceX is improving the turbine blades. They will continue launching the version with the weak turbine blanes for some time, and it's very unlikely it will cause ANY problems at all, and then later the will release the block 5 model of the rocket with more robust turbine blades.
It seem that the whole issue is "leaked" by some guy who is pissed to spaceX/Elon for something and the media is always eager to post this kind of "leaks" without really understanding what it is all about.
His Gulfstream G650 requires about 2000 meters in full load to take off, but can land in less than one km.
Dassault Falcon 7X needs 1750 meters to take off in full load, and can land in less than one km.
So Hawthorne airfield is not enough for G650, but Dassault Falcon 7X with tanks filled only to half could propably takeoff from Hawthorne, and could still fly to anywhere in North America, only when flying to other continents it would have to be refuelled.
Soyuz rocket launch cost is 48-61 millions depending on configuration (LEO launches cheaper due no upper stage) Soyuz capasity to is 8.2 tonnes to LEO and 3.25 tonnes to GTO.
Falcon 9 expendable capasity is 22.8 tonnes to LEO and 8.3 tonnes to GTO, and Falcon 9(stage 1 recoverable) capasity is over 13 tonnes to LEO(propably much more) and 5.5 tonnes to GTO.
So, falcon 9 on fully expendable mode lifts over 2.5x more than soyuz, and falcon 9 on stage 1 recoverable mode lift over 1.5 x more than soyuz.
This means that: for LEO launches, reused reusable(assuming the 30% discount) falcon 9 is 10% cheaper than Soyuz, while lifting over 1.5 times more. for GTO launches, reused reusable(assuming the 30% discount) falcon 9 is 29% cheaper than Soyuz, while lifting about 1.7 times more.
The latency of RAM is improving very slowly, only something like 2x-4x improvement in last 20 years.
Only the bandwidth of the memory is growing faster, and that's just because they have been putting more dram cells in parallel, always doing bigger data transfers and having faster memory bus.
Same is true for hard disk drive speed, the rotation speeds dictates the random access latency and the rotation speed of average hard disk has only gone up from 4200 or 5400 to 7200 rpm in the last 20 years, meaning only 1.7 or 1.33 times improvement in random access latency
Though replacing hard disks with flash-based SSD storage has improved latency by a huge margin.
The A-10 flies at about 420 MPH. Even 1980s fighter jets fly at mach 2, about the same speed as the bullets from the A-10 gun. An A-10 going after a fighter is literally the same ratio as a scooter going after a Ferrari.
Don't misunderstand, scooters are good. They are useless for chasing down sports cars, and an A-10 is just as useless for engaging enemy fighters. The fighters would (and do) fly by as if the A-10 is standing still.
Actually, even fighters from 1950's can fly at mach 2, BUT: Even those 1980's fighters won't be flying at mach 2 at 95% of their time. They can only fly at mach 2 at high altitudes on straight line, full afterburner, wasting huge amount of duel.
Practically all dogfights happen at subsonic velocities. When you start doing high-g manouvers the velocity drops to subsonic very quickly.
> no known aircraft can survive the A-10's gun. It is the most powerful dogfight cannon
The bullets from the A-10's gun go about the same speed as the fighter. So if somehow, magically, the A-10 got on the fighter's tail and fired, the bullet probably couldn't catch up to the fighter. If it was fired off angle, it might hit the fighter at 30 MPH relative speed - not enough to dent the sheetmetal.
Survive that A-10s gun? No jet fighter in the last 40 years can be HIT by the A-10 gun unless the fighter is either a) parked or b) intentionally flying toward the A-10 without shooting it down.
This part is so incorrect....
The speed of bullets from GAU-8 is 1070 m/s. Top speed of the worlds fastest jet fighter(mig-25) is ~890m/s flying on straight line on high altitude, with afterburner, but only ~333 m/s on low altitude. Top speed of most modern jet fighters is in the class of 700m/s. (high, straigt line, full afterburner)
Common speed of modern jet fighters during dogfight is about 250-350m/s , 3-4 times slower than the bullets from GAU-8.
A-10 is actually quite good plane for shooting down slow low-flying aircrafts such as helicopters. It can use AIM-9 missile from slightly longer range, and from the close range the GAU-8 is very deadly. And because it can fly lower and slower it can more easily hit those slow low-flying targets than faster, higher-flying aircrafts can.
So what you're saying is that the plane is incapable of dogfighting unless you throw away one of the design requirements?
No.
Here is an example. The numbers are from hat, not actual numbers.
You go to fight 600 miles away. You load the F-35 to it's full internal fuel load. When you arrive to the fighting location, you now have 50% fuel in your tanks, and you have the same T/W and wing loading ratios than in the report.
You also go to fight 600 miles away in F-16. You load it's internal tanks full, AND add two drop tanks. When you arrive to the location, your external tanks are empty, and you drop then. You are then fighting with full internal fuel load. Now, your real-world performance is WORSE than the numbers in the report, because you are fighting with full fuel tanks instead of half fuel tanks, and the report used fuel tanks that were half empty, half full.
Or, you go to fight 300 miles away. You load F-35 to half of it's internal fuel load. When you arrive the fighting location, you have 25% fuel in your fuel tanks, and you have much better T/W and wing loading ratios than in the report, as the report fuel tanks that were half empty, half full.
or, you load F-16 to it's full internal fuel load, and when you arrive to the fighting locaiton, you have 50% fuel left in your tanks, and you have the same T/W and wing loading ratios than in the report.
In all real-world cases, you have have smaller relative amount of fuel in your fuel tanks in F-35 than in F-16, and the numbers will shift in favour of F-35.
The design requirements say that F-35 has to fly a long distance with internal fuel, and that's just to make it stealthy, but not needing to use external fuel tanks.
So they did their thrust/weight and wing loading comparison by loading all jets with 50% of internal fuel.
This comparison favours planes with small internal fuel tanks.
F-35 has huge internal fuel tanks, it can fly much longer with internal fuel than most other jet fighters (which need external fuel tanks, which are NOT calculated in these numbers) to fly as far.
Load all jets with amount of fuel that makes them fly about equally far and the numbers switch considerably, on favour of F-35.
Micron Automata can solve NP-hard programs very quickly, and it's not quantum computer.
It abandons the Von Neumann model we have been using or last 60 years and can achieve very high parallelism. And it requires a very different style of programming.
But it's not quantum computer. And it's actually working, running in Micron's labs and very soon coming to market.
Quantum computers are hype that's not really working, Micron automata is the real thing achieving mostly the same benefits.
This same myth keeps being repeated by people who don't really understand the details on how processors internally work.
Actually, YOU are wrong.
You cannot just change the decoder, the instruction set affect the internals a lot:
All the reason you list could all be "fixed in software".
No, they cannot. OR the software will be terible slow , like 2-10 times slowdown.
The fact that silicon designed by Intel handles opcode in a way a little bit better optimized toward being fed from a x86-compatible frontend is just specific optimisation.
Opcodes are irrelevant. They are easy to translate. What matters are the differences in the semantics of the instructions. X86 instructions update flags. This adds dependencies between instructions. Most RISC processoers do not have flags at all. This is semantics of instructions, and they differ between ISA's.
Simply doing the same stuff with another RISCy back-end, i.e: interpreting the same ISA fed to the front-end, will simply require each x86 ISA being executed as a different set of micro-instructions. (some that are handled as single ALU opcode on Intel's silicon might require a few more instruction, but that's about the different).
The backend, the micro-instrucions in x86 CPUs are different than the instructions in RISC CPU's. They differ in the small details I tried to explain.
You could switch the frontend and speak a completely different instruction set. Simply if the two ISA are radically different, the result wouldn't be as efficient as a chip designed with that ISA in mind. (You would need a much bigger and less efficient microcode, because of all the reasons you list. They won't STOP intel from making a chip that speaks something else.
Intel did this, they added x86 decoder to their first itanium chips. And. They did not only add the frontend, they added some small pieces to their backend so that it could handle those strange x86 semantic cases nicely. But the perfromance was still so terrible that nobody ever used it to run x86 code, and then they created a software translator that translated x86 code into itanium code, and that was faster, though still too slow.
Not only is this possible, but this was INDEED done.
There was an entire company called "Transmeta" whose business was centered around exactly that: Their chip, the "Crusoe" was compatible with x86. - But their chip was actually a VLIW chips, with the front-end being 100% pure software. Absolutely as remote from a pure x86 core as possible.'
The backend of Crusoe was designed completely x86 on mind, all the execution units contained the small quirks in a manner which made it easy to emulate x86 with it. The backend of Crusoe contains things like:
* 80-bit FPU, * x86-compatible virtual memory page table format(one very important thing I forgot from my original list couple of posts ago; Memory accesses get VERY SLOW if you have to emulate virtual memory) * support for partial register writes(to emulate 8- and 16-bit subregisters like al, ah,ax )
All these were made to make binary translation from x86 easy and reasonable fast.
Some of what you said is legitimate. Most of it is irrelevant, since it does not speak to the postulate. You're speaking of issues which will affect performance. So what? You'd have a less-performant processor in some cases, and it would be faster in others.
No.
1) if the codition codes work totally differently, they don't work.
2) The data paths needed for separate and compined FP and integer regs are so different that it makes absolutely NO sense to have them together in chip that runs x86 ISA, even though it's possible.
3) If you don't have those x86-compatible address calculation units, you have to break most of memory ops into more micro-ops OR even run them with microcode. Both are slow. And if you have a RISC chip you want to have only the address calculation units you need for your simple base+offset addressing.
4) In the basic RISC pipeline there are two operands, one output/instruction. There are no data paths for two results, you cannot execute operations with multiple outputs such as x86 muliply which produces 2 values(low and high part of result), unless you do something VERY SLOW.
6) IF your RISC instruction set says you have aligned memory operations, you design your LSU to have only those, as it makes the LSU's much smaller, simpler and faster. But you need unaligned accesses for x86.
9) If your FPU calculates with different bit width, it calculates wrongly.
After AMD lost the license to manufacture Intel i486 processors, together with other people, they were forced to design their own chip from the ground up. So they basically used one of the 29k RISC processors and put an x86 frontend on it.
This was their plan, but it ended up being quite much harder than they originally thought, and K5 came out much later, much different and much slower than planned. There are quite a lot of thigns that have to be done differently (some of them are explained in my another post)
That is correct. Every time this comes up I like to spark a debate over what I perceive as the uselessness of referring to an "instruction set architecture" because that is a bullshit, meaningless term and has been ever since we started making CPUs whose external instructions are decomposed into RISC micro-ops. You could switch out the decoder, leave the internal core completely unchanged, and have a CPU which speaks a different instruction set. It is not an instruction set architecture. That's why the architectures themselves have names. For example, K5 and up can all run x86 code, but none of them actually have logic for each x86 instruction. All of them are internally RISCy. Are they x86-compatible? Obviously. Are they internally x86? No, nothing is any more.
This same myth keeps being repeated by people who don't really understand the details on how processors internally work.
You cannot just change the decoder, the instruction set affect the internals a lot:
1) Condition handling is totally different on different instruciton sets. This affect the banckend a lot. X86 has flags registers, many other architectures have predicate registers, some predicate registers with different conditions.
2) There are totally different number of general purpose and floating point registers. The register renamer makes this a smaller difference, but then there is the fact that most RISC's use same registers for both FPU and integer, X86 has separate registers for both. And this totally separates them, the internal buses between the register files and function units in the processor are done very differently.
3) Memory addressing modes are very different. X86 still does relatively complex address calculations on single micro-operation, so it has more complex address calculation units.
4) Whether there are operations with more than 2 inputs, or more than 1 output has quite big impact on what kind of internal buses are needed, how many register read and write ports are needed.
5) There are a LOT of more complex instructions in X86 ISA which are not split into micro-ops but handled via microcode. the microcode interpreter is totally missing on pure RISCs ( but exists on some not-so pure RISC's like Powe/PowerPC).
6) Instruction set dictates the memory aligment rules. Architectures with more strict alignment rules can have simples load-store-units.
7) Instruction set dictatetes the multicore memory ordering rules. This may affect the load-store units, caches and buses.
8) Some instructions have different bitnesses in different architectures. For example x86 has N x X -> 2N wide multiply operations which most RISC's don't have. So x86 needs bigger/different multiplier than most RISCs.
9) X87 FPU values are 80-bit wide(truncated to 64-bit when storing/loading). Practically all the other CPU's have maximum of 64-bit wide FPU values (though some versions Power have support for 128-bit FP numbers also)
They are seriously comparing some 90nm process with much better intel 32nm and 45 nm processes.
They have just taken some random cores made on random (and uncomparable) manufacturing technologies, throw couple of benchmarks and try to declare universal results based on these.
Few facts about the benchmarks setup and the cores cores:
1) They use ancient version of GCC. ARM suffers this much more than x86. 2) Bobcat is relatively balanced core, no bad bottlenecks. mfg tech is cheap, not high performance but relatively small/new. 3) Cortex A8 and A9 are really starved by bad cache design. Newer A7 and A12 would be similar in area and powet consumption but much better in performance and performance/power. There are also manufactured on old cheap mfg processes, which hurt them. Use modern manufacturing tech and results are quite much better 4) Their loonson is made on ANCIENT technology. With modern mfg tech it would be many times better on performance/power. 5) The cortex A15, even though made on 32nm process, is cheap process, not much better than intel's 45nm process and much worse than intel's 32nm. Also it's known to be a "power hog"-design. Qualcomm's Krait has similar performance level, but with much lower power.
- Single-thread performance matters much more than multi-thread performance, and Kaveri has almost twice the single-thread performance of the Xbone and PS4 chips.
- Memory bandwidth is expensive. You either need wide and expensive bus, or expensive low-capasity graphics DRAM which need soldering, and means you are limited to 4 GiB of memory(with the highest capasity GDDR chips out there), with zero possibility of late upgrading it, or both(and MAYBE get 8 giB of soldered memory). Though there has been rumours that Kaveri might support GDDR5, for configurations with only 4 GiB of soldered memory.
- And when you have that limited memory bandwidth, it does not make sense to waste die space on creating monster GPU which is starved by the lack of bandwidth.
- ALL the mentioned chips are of same generation. All support cache-coherent unified memory.
As PC chip, Kaveri makes much more sense:
- Software that matters on PC cannot use 8 threads. Kaveri is much faster at most software - Weaker GPU side, ability to use cheap DDR3, and narrower memory bus makes Kaveri chip and kaveri-bases systems cheaper to manufacture - The CPU can be socket, need to to be soldered, and the memory chips can use DIMMs instead of soldering to motherboard. Ability to upgrade something and system manufacturers to easily create different configurations.
WP has crappy multitasking, and all your data are belong to Microsoft.
With IOS all your data are belong to Apple. And everything is controller by Apple.
With Android all your data are belong to Google, and performance is bad.
With Symbian the user owns his data, but performance is bad, sw development is really pain, and UI is bad. RIP.
What is needed is operating system that allows the user to own his data, has good performance, and allows the user to use the device the way he wants. Meego/Mer gives this.
Jolla means a very small sailing boat - not meant for rescue, but meant for people who want to go sailing alone on a very small boat. (who either cannot afford bigger boat or just likes very small boats)
Jollas cant be used as rescue boats, they are too small for that.
Software isn't the bottleneck. Caches are *tiny* compared to the size of even single functions in modern programs, which means they get flooded repeatedly, which in turn means that you're pulling from main memory a lot more than you'd like.
Wrong.
The code size of average function is much smaller than instruction cache for any modern processor. And then there are L2 and L3 caches.
Instruction fetch needing to go to main memory is quite rare.
And then about data.. depends totally on what the program does.
Multi-core CPUs aren't (as a rule) fully independent - they share caches and share I/O lines, which in turn means that the effective capacity is slashed as a function of the number of active cores. Cheaper ones even share(d) the FPU, which was stupid.
None one of the CPU's sharing FPU with multiple HW threads are cheap.
Sun Niagara I had slow shared FPU, but the chip was not cheap
AMD Bulldozer, which usually has sucky performance, sucks less on code which uses the shared FPU.
FPU operations just have long latencies and there are always lots of data dependencies, so in practice you cannot utilize FPU well from one threads, you need to feed instructions from multiple treads.
Intel uses HyperThreading for this, AMD Bulldozer it's CMT/shared FPU/module. GPU's are barrel processors for the same reason.
The bottleneck problem is typically solved by increasing the size of the on-chip caches OR by adding an external cache between main memory and the CPU.
Much more often the bottleneck is between the levels of the chip's caches. The big outer level caches are slow and processors spend quite often small time waiting for data coming from them. And if you increase the size of the last level caches, you make them even slower.
One of the reason's for bulldozer's sucky performance is because it has small L1 caches(so it needs to fetch data deom L2 cache often), but big and slow L2 cache. So there is this relatively long L2 latency happening quite often.
External cache.. has not been been used for about 10 years by Intel or AMD. It's either slow or expensive, and usually both. Now when even internal caches can easily be made with sizes over 10 megabytes, the external cache has to be very expensive in order to compete with internal caches, and still it only makes sense on some server workloads.
After that, it depends on whether the bottleneck is caused by bus contention or by slow RAM. Bus contention would require memory to be banked with each bank on an independent local bus. Slow RAM would require either faster RAM or smarter (PIM) RAM. (Smart RAM is RAM that is capable of performing very common operations internally without requiring the CPU. It's unpopular with manufacturers because they like cheap interchangeable parts and smart RAM is neither cheap nor interchangeable.)
Smart RAM is a dream, and a research topic in universities. It's uncommon because it does not (yet) exist.
And most of the problems/algorithms are not solveable by "simple" smart ram that can only operation on data near each others. And it you try to make it even smarter, then you end up making it costlier and slower, it will become just chip with multicore processor and memory on same chip.
There are some computational tasks where smart ram would improve the performance by great magnitude, but for the >90% of all the other problems, it has quite little use.
When nokia deciced to open source Symbian, they did not understand the ways how open source software/development model works. You cannot take a closed-source code and think that when you open the source, suddently thousands of other people will come to help you and do your work for you.
The amount of people who actually downloaded the symbian os source code and succesfully compiled it themselves outside Nokia and some other big phone manufacturers can propably be calculated with fingers of one hand.
SymbianOS was piece of terribly written code that used very strange coding practices, and getting it to compile was quite hard. By just giving this kind of code to public does not create any kind of "open source momentum". No people are interested in contributing to it when they cannot get any benefit from their changes, and when making those changes is so hard.
So, in the end, nobody loses when the source is closed.
Slashdot Mirror
LLVM bitcode contains (and needs) the datalayout of the target. This datalayout means such things as default data sizes and alignment rules. Pointer size is different for 32- and 64-bit architectures, so same LLVM bitcode cannot work in both 32- and 64-bit mode.
So, bitcode alone cannot explain portability to 64-bit.
It might be that the development tools have compiled separate bitcode files for 32-and 64-bit architectures.
I live in Finland, so few comments about the SAK.
SAK is worker union that has jammed to 1970's.
There are only 2 things SAK is capable of doing:
1) Shouting "bigger pays of we will go to strike"
2) Shouting "you may not do any improvements for more flexible work contracts, or we will go to strike".
Absolutely no understanding that the world economy has changed since 1970's, and absolutely no understanding od thet fact that finland has been belonginf to EU for over 20 years should make things very different than things were in 1970s.
Also absolutely no understanding of the fact that Nokia was holding Finnish economy high and now when Nokia is no longer making mobile phones, Finnish economy is doing much worse and they cannot require so high wages anymore.
In Finland the worker unions are way too strong, they have some rights (or actually wrongs) worker unions in other countries do not have:
1) The worker unions also decide how much is paid to employers that are not members of the union.
2) You get tax rebates for belonging to worker union.
3) In order to get better unemployment benefits you HAVE to belong to some unemployment fund, even though only about 1% of the unemployment compensation money comes from the unemployment fund, 99% comes directly from the goverment. Most of these unemployment funds are ran by the worker unions. (fortunately there is also one private on, "YTK", "common unemployment fund", but many people do not know it exists)
Falcon 9 and the space shuttle are the only rockets whose engines have survived the launch so that they could have been inspected. And similar cracks have been found on shuttle engines too. Many other rocket engines very probbly have generated similar cracks during their burn, but those have not been inspected because the engines have gone to the bottom of the ocean.
There have been 28 launches of falcon. During those 28 launches, 279 Merlin 1-series engines have been used, with only 1 major engine problem. And even in that case, the rocket delivered the primary payload to the desired orbit; Each falcon 9 has 10 engines and only on of those 10 engines is critical whose failure leads to mission failure.
So, until now, the engines have had 99.64% reliability, and due the engine redundancy, only 10% of engine failures means mission failure on most launches(upper stage engine may not fail), meaning mission failure probability of 0.04% due failing engine if the engines keep working equally well in the future than they previously have been working.
No, the this turbine thing is not a big problem. Bigger problems are elsewhere, and spaceX is improving the turbine blades. They will continue launching the version with the weak turbine blanes for some time, and it's very unlikely it will cause ANY problems at all, and then later the will release the block 5 model of the rocket with more robust turbine blades.
It seem that the whole issue is "leaked" by some guy who is pissed to spaceX/Elon for something and the media is always eager to post this kind of "leaks" without really understanding what it is all about.
Hawthorne airfield is 1511 meters.
His Gulfstream G650 requires about 2000 meters in full load to take off, but can land in less than one km.
Dassault Falcon 7X needs 1750 meters to take off in full load, and can land in less than one km.
So Hawthorne airfield is not enough for G650, but Dassault Falcon 7X with tanks filled only to half could propably takeoff from Hawthorne,
and could still fly to anywhere in North America, only when flying to other continents it would have to be refuelled.
Soyuz rocket launch cost is 48-61 millions depending on configuration (LEO launches cheaper due no upper stage)
Soyuz capasity to is 8.2 tonnes to LEO and 3.25 tonnes to GTO.
Falcon 9 expendable capasity is 22.8 tonnes to LEO and 8.3 tonnes to GTO,
and Falcon 9(stage 1 recoverable) capasity is over 13 tonnes to LEO(propably much more) and 5.5 tonnes to GTO.
So, falcon 9 on fully expendable mode lifts over 2.5x more than soyuz, and falcon 9 on stage 1 recoverable mode lift over 1.5 x more than soyuz.
This means that:
for LEO launches, reused reusable(assuming the 30% discount) falcon 9 is 10% cheaper than Soyuz, while lifting over 1.5 times more.
for GTO launches, reused reusable(assuming the 30% discount) falcon 9 is 29% cheaper than Soyuz, while lifting about 1.7 times more.
The "deep learning" benchmark is a GPGPU workload which does practically nothing on CPU.
Nvidia has just made a SoC Chip that has about equally fast iGPU than what Intel has, for a lower energy consumption.
But in CPU performance, the Skylake is MUCH faster.
The latency of RAM is improving very slowly, only something like 2x-4x improvement in last 20 years.
Only the bandwidth of the memory is growing faster, and that's just because they have been putting more dram cells in parallel, always doing bigger data transfers and having faster memory bus.
Same is true for hard disk drive speed, the rotation speeds dictates the random access latency and the rotation speed of average hard disk has only gone up from 4200 or 5400 to 7200 rpm in the last 20 years, meaning only 1.7 or 1.33 times improvement in random access latency
Though replacing hard disks with flash-based SSD storage has improved latency by a huge margin.
The A-10 flies at about 420 MPH. Even 1980s fighter jets fly at mach 2, about the same speed as the bullets from the A-10 gun. An A-10 going after a fighter is literally the same ratio as a scooter going after a Ferrari.
Don't misunderstand, scooters are good. They are useless for chasing down sports cars, and an A-10 is just as useless for engaging enemy fighters. The fighters would (and do) fly by as if the A-10 is standing still.
Actually, even fighters from 1950's can fly at mach 2, BUT:
Even those 1980's fighters won't be flying at mach 2 at 95% of their time. They can only fly at mach 2 at high altitudes on straight line, full afterburner, wasting huge amount of duel.
Practically all dogfights happen at subsonic velocities. When you start doing high-g manouvers the velocity drops to subsonic very quickly.
> no known aircraft can survive the A-10's gun. It is the most powerful dogfight cannon
The bullets from the A-10's gun go about the same speed as the fighter. So if somehow, magically, the A-10 got on the fighter's tail and fired, the bullet probably couldn't catch up to the fighter. If it was fired off angle, it might hit the fighter at 30 MPH relative speed - not enough to dent the sheetmetal.
Survive that A-10s gun? No jet fighter in the last 40 years can be HIT by the A-10 gun unless the fighter is either a) parked or b) intentionally flying toward the A-10 without shooting it down.
This part is so incorrect....
The speed of bullets from GAU-8 is 1070 m/s.
Top speed of the worlds fastest jet fighter(mig-25) is ~890m/s flying on straight line on high altitude, with afterburner, but only ~333 m/s on low altitude.
Top speed of most modern jet fighters is in the class of 700m/s. (high, straigt line, full afterburner)
Common speed of modern jet fighters during dogfight is about 250-350m/s , 3-4 times slower than the bullets from GAU-8.
A-10 is actually quite good plane for shooting down slow low-flying aircrafts such as helicopters. It can use AIM-9 missile from slightly longer range, and from the close range the GAU-8 is very deadly. And because it can fly lower and slower it can more easily hit those slow low-flying targets than faster, higher-flying aircrafts can.
So what you're saying is that the plane is incapable of dogfighting unless you throw away one of the design requirements?
No.
Here is an example. The numbers are from hat, not actual numbers.
You go to fight 600 miles away. You load the F-35 to it's full internal fuel load. When you arrive to the fighting location, you now have 50% fuel in your tanks, and you have the same T/W and wing loading ratios than in the report.
You also go to fight 600 miles away in F-16. You load it's internal tanks full, AND add two drop tanks. When you arrive to the location, your external tanks are empty, and you drop then. You are then fighting with full internal fuel load. Now, your real-world performance is WORSE than the numbers in the report, because you are fighting with full fuel tanks instead of half fuel tanks, and the report used fuel tanks that were half empty, half full.
Or, you go to fight 300 miles away. You load F-35 to half of it's internal fuel load. When you arrive the fighting location, you have 25% fuel in your fuel tanks, and you have much better T/W and wing loading ratios than in the report, as the report fuel tanks that were half empty, half full.
or, you load F-16 to it's full internal fuel load, and when you arrive to the fighting locaiton, you have 50% fuel left in your tanks, and you have the same T/W and wing loading ratios than in the report.
In all real-world cases, you have have smaller relative amount of fuel in your fuel tanks in F-35 than in F-16, and the numbers will shift in favour of F-35.
The design requirements say that F-35 has to fly a long distance with internal fuel, and that's just to make it stealthy, but not needing to use external fuel tanks.
So they did their thrust/weight and wing loading comparison by loading all jets with 50% of internal fuel.
This comparison favours planes with small internal fuel tanks.
F-35 has huge internal fuel tanks, it can fly much longer with internal fuel than most other jet fighters (which need external fuel tanks, which are NOT calculated in these numbers) to fly as far.
Load all jets with amount of fuel that makes them fly about equally far and the numbers switch considerably, on favour of F-35.
Micron Automata can solve NP-hard programs very quickly, and it's not quantum computer.
It abandons the Von Neumann model we have been using or last 60 years and can achieve very high parallelism.
And it requires a very different style of programming.
But it's not quantum computer. And it's actually working, running in Micron's labs and very soon coming to market.
Quantum computers are hype that's not really working, Micron automata is the real thing achieving mostly the same benefits.
Launch abort system could have saved the 7 astronauts of challenger accident. But shuttle did not have launch abort system.
RD-170 is more powerful than F-1. Though it's multi-chamber engine.
Space shuttle solid boosters are also much more powerful than both F-1 and RD-170.
F-1 is the most powerful single-chamber liquid-fuel engine.
RD-180 flew it's first flight in 2000, and it's based on RD-170 which flew it's first flight in 1987.
So not designed in seventies.
AK-26 / NK-33 (used in Antares rocket) is the engine developed in sixties and manufactured in seventies.
This same myth keeps being repeated by people who don't really understand the details on how processors internally work.
Actually, YOU are wrong.
You cannot just change the decoder, the instruction set affect the internals a lot:
All the reason you list could all be "fixed in software".
No, they cannot. OR the software will be terible slow , like 2-10 times slowdown.
The fact that silicon designed by Intel handles opcode in a way a little bit better optimized toward being fed from a x86-compatible frontend is just specific optimisation.
Opcodes are irrelevant. They are easy to translate. What matters are the differences in the semantics of the instructions.
X86 instructions update flags. This adds dependencies between instructions. Most RISC processoers do not have flags at all.
This is semantics of instructions, and they differ between ISA's.
Simply doing the same stuff with another RISCy back-end, i.e: interpreting the same ISA fed to the front-end, will simply require each x86 ISA being executed as a different set of micro-instructions. (some that are handled as single ALU opcode on Intel's silicon might require a few more instruction, but that's about the different).
The backend, the micro-instrucions in x86 CPUs are different than the instructions in RISC CPU's. They differ in the small details I tried to explain.
You could switch the frontend and speak a completely different instruction set. Simply if the two ISA are radically different, the result wouldn't be as efficient as a chip designed with that ISA in mind. (You would need a much bigger and less efficient microcode, because of all the reasons you list. They won't STOP intel from making a chip that speaks something else.
Intel did this, they added x86 decoder to their first itanium chips. And. They did not only add the frontend, they added some small pieces to their backend so that it could handle those strange x86 semantic cases nicely.
But the perfromance was still so terrible that nobody ever used it to run x86 code, and then they created a software translator that translated x86 code into itanium code, and that was faster, though still too slow.
Not only is this possible, but this was INDEED done.
There was an entire company called "Transmeta" whose business was centered around exactly that:
Their chip, the "Crusoe" was compatible with x86.
- But their chip was actually a VLIW chips, with the front-end being 100% pure software. Absolutely as remote from a pure x86 core as possible.'
The backend of Crusoe was designed completely x86 on mind, all the execution units contained the small quirks in a manner which made it easy to emulate x86 with it. The backend of Crusoe contains things like:
* 80-bit FPU,
* x86-compatible virtual memory page table format(one very important thing I forgot from my original list couple of posts ago; Memory accesses get VERY SLOW if you have to emulate virtual memory)
* support for partial register writes(to emulate 8- and 16-bit subregisters like al, ah,ax )
All these were made to make binary translation from x86 easy and reasonable fast.
Some of what you said is legitimate. Most of it is irrelevant, since it does not speak to the postulate. You're speaking of issues which will affect performance. So what? You'd have a less-performant processor in some cases, and it would be faster in others.
No.
1) if the codition codes work totally differently, they don't work.
2) The data paths needed for separate and compined FP and integer regs are so different that it makes absolutely NO sense to have them together in chip that runs x86 ISA, even though it's possible.
3) If you don't have those x86-compatible address calculation units, you have to break most of memory ops into more micro-ops OR even run them with microcode. Both are slow. And if you have a RISC chip you want to have only the address calculation units you need for your simple base+offset addressing.
4) In the basic RISC pipeline there are two operands, one output/instruction. There are no data paths for two results, you cannot execute operations with multiple outputs such as x86 muliply which produces 2 values(low and high part of result), unless you do something VERY SLOW.
6) IF your RISC instruction set says you have aligned memory operations, you design your LSU to have only those, as it makes the LSU's much smaller, simpler and faster. But you need unaligned accesses for x86.
9) If your FPU calculates with different bit width, it calculates wrongly.
And
After AMD lost the license to manufacture Intel i486 processors, together with other people, they were forced to design their own chip from the ground up. So they basically used one of the 29k RISC processors and put an x86 frontend on it.
This was their plan, but it ended up being quite much harder than they originally thought, and K5 came out much later, much different and much slower than planned. There are quite a lot of thigns that have to be done differently (some of them are explained in my another post)
That is correct. Every time this comes up I like to spark a debate over what I perceive as the uselessness of referring to an "instruction set architecture" because that is a bullshit, meaningless term and has been ever since we started making CPUs whose external instructions are decomposed into RISC micro-ops. You could switch out the decoder, leave the internal core completely unchanged, and have a CPU which speaks a different instruction set. It is not an instruction set architecture. That's why the architectures themselves have names. For example, K5 and up can all run x86 code, but none of them actually have logic for each x86 instruction. All of them are internally RISCy. Are they x86-compatible? Obviously. Are they internally x86? No, nothing is any more.
This same myth keeps being repeated by people who don't really understand the details on how processors internally work.
You cannot just change the decoder, the instruction set affect the internals a lot:
1) Condition handling is totally different on different instruciton sets. This affect the banckend a lot. X86 has flags registers, many other architectures have predicate registers, some predicate registers with different conditions.
2) There are totally different number of general purpose and floating point registers. The register renamer makes this a smaller difference, but then there is the fact that most RISC's use same registers for both FPU and integer, X86 has separate registers for both. And this totally separates them, the internal buses between the register files and function units in the processor are done very differently.
3) Memory addressing modes are very different. X86 still does relatively complex address calculations on single micro-operation, so it has more complex address calculation units.
4) Whether there are operations with more than 2 inputs, or more than 1 output has quite big impact on what kind of internal buses are needed, how many register read and write ports are needed.
5) There are a LOT of more complex instructions in X86 ISA which are not split into micro-ops but handled via microcode. the microcode interpreter is totally missing on pure RISCs ( but exists on some not-so pure RISC's like Powe/PowerPC).
6) Instruction set dictates the memory aligment rules. Architectures with more strict alignment rules can have simples load-store-units.
7) Instruction set dictatetes the multicore memory ordering rules. This may affect the load-store units, caches and buses.
8) Some instructions have different bitnesses in different architectures. For example x86 has N x X -> 2N wide multiply operations which most RISC's don't have. So x86 needs bigger/different multiplier than most RISCs.
9) X87 FPU values are 80-bit wide(truncated to 64-bit when storing/loading). Practically all the other CPU's have maximum of 64-bit wide FPU values (though some versions Power have support for 128-bit FP numbers also)
They are seriously comparing some 90nm process with much better intel 32nm and 45 nm processes.
They have just taken some random cores made on random (and uncomparable) manufacturing technologies, throw couple of benchmarks and try to declare universal results based on these.
Few facts about the benchmarks setup and the cores cores:
1) They use ancient version of GCC. ARM suffers this much more than x86.
2) Bobcat is relatively balanced core, no bad bottlenecks. mfg tech is cheap, not high performance but relatively small/new.
3) Cortex A8 and A9 are really starved by bad cache design. Newer A7 and A12 would be similar in area and powet consumption but much better in performance and performance/power. There are also manufactured on old cheap mfg processes, which hurt them. Use modern manufacturing tech and results are quite much better
4) Their loonson is made on ANCIENT technology. With modern mfg tech it would be many times better on performance/power.
5) The cortex A15, even though made on 32nm process, is cheap process, not much better than intel's 45nm process and much worse than intel's 32nm. Also it's known to be a "power hog"-design. Qualcomm's Krait has similar performance level, but with much lower power.
- Single-thread performance matters much more than multi-thread performance, and Kaveri has almost twice the single-thread performance of the Xbone and PS4 chips.
- Memory bandwidth is expensive. You either need wide and expensive bus, or expensive low-capasity graphics DRAM which need soldering, and means you are limited to 4 GiB of memory(with the highest capasity GDDR chips out there), with zero possibility of late upgrading it, or both(and MAYBE get 8 giB of soldered memory). Though there has been rumours that Kaveri might support GDDR5, for configurations with only 4 GiB of soldered memory.
- And when you have that limited memory bandwidth, it does not make sense to waste die space on creating monster GPU which is starved by the lack of bandwidth.
- ALL the mentioned chips are of same generation. All support cache-coherent unified memory.
As PC chip, Kaveri makes much more sense:
- Software that matters on PC cannot use 8 threads. Kaveri is much faster at most software
- Weaker GPU side, ability to use cheap DDR3, and narrower memory bus makes Kaveri chip and kaveri-bases systems cheaper to manufacture
- The CPU can be socket, need to to be soldered, and the memory chips can use DIMMs instead of soldering to motherboard. Ability to upgrade something and system manufacturers to easily create different configurations.
argh, again this kind of misleading headline that makes the people who only read the headline think a perpetual machine is finally invented.
The energy comes from aluminium, aluminium "burning" into aluminium-oxide.
Putting the "converting water into hydrogen" into headline is misleading reporting.
WP has crappy multitasking, and all your data are belong to Microsoft.
With IOS all your data are belong to Apple. And everything is controller by Apple.
With Android all your data are belong to Google, and performance is bad.
With Symbian the user owns his data, but performance is bad, sw development is really pain, and UI is bad. RIP.
What is needed is operating system that allows the user to own his data, has good performance, and allows the user to use the device the way he wants.
Meego/Mer gives this.
I'm a finn,so I know what "Jolla" means.
Jolla means a very small sailing boat - not meant for rescue, but meant for people who want to go sailing alone on a very small boat.
(who either cannot afford bigger boat or just likes very small boats)
Jollas cant be used as rescue boats, they are too small for that.
Software isn't the bottleneck. Caches are *tiny* compared to the size of even single functions in modern programs, which means they get flooded repeatedly, which in turn means that you're pulling from main memory a lot more than you'd like.
Wrong.
The code size of average function is much smaller than instruction cache for any modern processor.
And then there are L2 and L3 caches.
Instruction fetch needing to go to main memory is quite rare.
And then about data.. depends totally on what the program does.
Multi-core CPUs aren't (as a rule) fully independent - they share caches and share I/O lines, which in turn means that the effective capacity is slashed as a function of the number of active cores. Cheaper ones even share(d) the FPU, which was stupid.
None one of the CPU's sharing FPU with multiple HW threads are cheap.
Sun Niagara I had slow shared FPU, but the chip was not cheap
AMD Bulldozer, which usually has sucky performance, sucks less on code which uses the shared FPU.
FPU operations just have long latencies and there are always lots of data dependencies, so in practice you cannot
utilize FPU well from one threads, you need to feed instructions from multiple treads.
Intel uses HyperThreading for this, AMD Bulldozer it's CMT/shared FPU/module.
GPU's are barrel processors for the same reason.
The bottleneck problem is typically solved by increasing the size of the on-chip caches OR by adding an external cache between main memory and the CPU.
Much more often the bottleneck is between the levels of the chip's caches.
The big outer level caches are slow and processors spend quite often small time waiting for data coming from them. And if you increase the size of the last level caches, you make them even slower.
One of the reason's for bulldozer's sucky performance is because it has small L1 caches(so it needs to fetch data deom L2 cache often), but big and slow L2 cache. So there is this relatively long L2 latency happening quite often.
External cache.. has not been been used for about 10 years by Intel or AMD. It's either slow or expensive, and usually both. Now when even internal caches can easily be made with sizes over 10 megabytes, the external cache has to be very expensive in order to compete with internal caches, and still it only makes sense on some server workloads.
After that, it depends on whether the bottleneck is caused by bus contention or by slow RAM. Bus contention would require memory to be banked with each bank on an independent local bus. Slow RAM would require either faster RAM or smarter (PIM) RAM. (Smart RAM is RAM that is capable of performing very common operations internally without requiring the CPU. It's unpopular with manufacturers because they like cheap interchangeable parts and smart RAM is neither cheap nor interchangeable.)
Smart RAM is a dream, and a research topic in universities. It's uncommon because it does not (yet) exist.
And most of the problems/algorithms are not solveable by "simple" smart ram that can only operation on data near each others. And it you try to make it even smarter, then you end up making it costlier and slower, it will become just chip with multicore processor and memory on same chip.
There are some computational tasks where smart ram would improve the performance by great magnitude, but for the >90% of all the other problems, it has quite little use.
When nokia deciced to open source Symbian, they did not understand the ways how open source software/development model works.
You cannot take a closed-source code and think that when you open the source, suddently thousands of other people will come to help you and do your work for you.
The amount of people who actually downloaded the symbian os source code and succesfully compiled it themselves outside Nokia and some other big phone manufacturers can propably be calculated with fingers of one hand.
SymbianOS was piece of terribly written code that used very strange coding practices, and getting it to compile was quite hard. By just giving this kind of code to public does not create any kind of "open source momentum". No people are interested in contributing to it when they cannot get any benefit from their changes, and when making those changes is so hard.
So, in the end, nobody loses when the source is closed.