To the point where it looks nothing like the concept car. IMO the concept looked different, while the current prototype looks like a Toyota Prius or Honda Civic.
No, not a good idea. What is the point in having a Cultural Revolution? Better to just split these companies which are too big to fail into smaller chunks, kick out the top management making sure they never work in that capacity anymore, enforce layers of separation between businesses and let them free. Restore the Glass–Steagall Act and separate commercial banking from investment banking.
AFAIK most X86 patents are hardware design patents. This is why Transmeta was able to sell their CPUs in the market. The hardware was little like X86, most of that part was software emulation.
A lot of the original X86 patents have expired and new processors are based on X86-64. AMD was the designer of X86-64 so I suppose they hold most of the patents. AMD has been quite liberal at licensing X86-64 in the past to companies such as VIA and yes, even Transmeta.
PS: NVIDIA already has a X86 CPU. When they bought ULi they got their very own 386 SoC chip. Heh.
RISC was a fad. It had its uses at a point, but no one really does RISC processors anymore. IBM POWER also does more involved instruction decoding than you will find in your RISC hardware design handbook. POWER 6 has several instructions which take more than 1 clock cycle to execute. POWER 6 has microcode. Intel Core has micro-op fusion. Load/store architectures aren't hot anymore.
The top two leading architecture segments in terms of $$$ are X86 and S/360, both CISC designs. ARM is supposedly RISC, but uses Thumb to compress instructions so they use less memory space.
Even if you port Windows, you still need applications. Otherwise you are better off using a Linux distro where you can recompile the apps most people use yourself.
The first Intel "quad core" processors (Intel Core 2 Quad) came in a multi-chip module with 2 chips per module, 2 cores per chip. So if that was a 4 core, POWER 7 is 16 core.
One good thing is motherboard chipsets are becoming irrelevant. At least in the desktop and mobile segment. Intel's increasingly bundling the north bridge with the CPU package. The next quarter you will see several 32nm processor releases which will make this more evident.
Still, if I was the FTC, I would force Intel to do two things: license the X86 ISA and its extensions, plus the CPU bus interface to all comers in a RAND basis.
No, Intel has been the real CPU leader since Intel Core came out. They use more advanced manufacturing technology faster. They do their process shrink a year before AMD. AMD still does not use high-k metal gates in their process. AMD's CPU design is also worse in many regards. Less total cache, no macro-op, and micro-op fusion, hyperthreading, etc. Intel's processors are also 4 issue, instead of 3 issue. AMD will only fix these design deficiencies in Bulldozer.
Really? Care to share any results that support that? I'm quite sure the peak flops you can achieve on the GPU are much higher than the limited SIMD capability of the CPU.
IIRC they claim 2.5-3x times more performance using a Tesla than using the CPUs in their workstation. Ignoring load time.
SSE enables a theoretical peak performance enhancement of 4x for SIMD amenable codes (e.g. you can do 4 parallel adds using vector SSE, in the time it takes to make 1 add using scalar SSE). In practice however you usually get like 3x more performance.
Theoretical SIMD performance for the GPU is very fine and nice, but in practice the small caches in current GPUs limit performance. CPUs also often have out-of-order execution support and other hardware which is too expensive in terms of transistors to implement in a GPU.
IMO the main problem here is that the programming model for the CPU is too complex since you need to use several different ways to express parallelism (SIMD/Multicore/Cluster) to get top performance.
At least a CPU program, when it crashes, does not bring down the whole OS. Memory protection? Pah, who needs such things... After all you never make coding mistakes. Right?
It is like MS-DOS programming all over again. Except the computer takes longer to reboot.
They use a worse algorithmic complexity algorithm in the paper because it actually performs better in the GPU than the other one. This happens in CPUs in several cases as well. When was the last time you saw someone using a Fibonacci heap? Memory footprint matters and taking advantage of the CPU caches matters. The paper also says nothing about CPU SIMD optimizations, which can make a program 3x faster if applied. That would make the performance the same as for the GPU system. Note that I am being generous here and actually ignoring the program setup time when they need to copy the data to the GPU. Because if I did not the pure CPU version would probably actually be faster.
They did the same thing with Centrino. A Centrino system contained a Pentium M processor with an Intel chipset. Intel gave kickbacks to companies which used both, in order to apply for the Centrino label.
A C++ compiler needs to know nothing about virtualization instructions. Much like it needs to know nothing about instructions for entering into protected mode.
While it is true that you need to do instruction scheduling to get top notch performance for a given processor, so the code is optimized for the number of functional units, cycle time of each instruction, etc, you should not disable a code path just because the CPU processor vendor name is different from "GenuineIntel". Such optimizations as you claim are never done, because otherwise there would be no forward compatibility for compiled code even within Intel's own processor products.
If there were published standards about how CPUs connect to the mainboard, and if the mainboard's major components were made interoperable (open BIOS, SMC, all that jazz--) that would be unbundling. The bottom line here is that if these parts were interchangable -- so that you didn't have to decide on the CPU first and then the rest of the system, that would be "unbundled". That would be a more fair marketplace than what exists right now.
It used to be this case. AMD K6 processors worked in Intel Pentium motherboards and vice-versa using the Socket 7 bus interface. Then Intel switched the processor bus to GTL and refused to license it to AMD. In fact, Intel even refused to license their bus design to chipset manufacturers at a point, because they wanted to corner that market as well. Intel sued VIA Technologies for doing AGTL bus compatible Pentium III chipsets. Only after Intel's own i820 RDRAM chipset turned out to be bugged to hell, and the third party OEMs started screaming they relented.
AMD, for Athlon, licensed the Digital Alpha EV-6 bus and had to make a separate infrastructure for manufacturing chipsets and motherboards. It was an open secret at the time that Intel pressured the Taiwanese motherboard manufacturers to not make any AMD compatible motherboards for Athlon. ASUS distributed their AMD motherboards in plain white boxes, without any ASUS markings, anywhere to escape Intel's wrath.
The flags do not lie. Processor manufacturers are not that stupid. There are different flags named 'sse4a', 'sse4_1', 'sse4_2'. Intel themselves initially only supported a part of the SSE 4 specification they made. This is why there are separate 'sse4_1' and 'sse4_2' flags. If a processor has a flag it means it implements a certain set of well defined instructions. Intel keeps its instruction extensions close to their vest usually, so AMD only gets to know them after Intel has already designed their own processor. AMD can sometimes do microcode changes to support instructions, in fact they did this in their initial SSE implementation, but other times you need to change the hardware functional units which takes years to do.
Intel Pentium II processors did not have SSE instructions either. No one asked for Intel to do additional work, just that they followed the proper way of doing it, which was no extra work at all. Intel's practice predates SSE 4 instruction development. It is known they did this even before Opteron came out.
No it was much worse than that. There is a CPU instruction named CPUID which tells you the processor family, manufacturer, and has a set of feature flags saying which extensions (e.g. SSE, SSE 2, 3DNow) that particular processor supports. Intel's compiler enabled SSE optimizations only if the processor manufacturer string was "GenuineIntel" and the processor family number was high enough, instead of checking in the flags vector if the processor supported SSE.
GCC and PGI have support for AMD processors. AMD often used these compilers for benchmark result submissions in the past. But the Intel C++ compiler is often faster at doing benchmark results since it has more advanced static optimization support.
There are standard sizes for rechargeable lithium ion cells. But different laptops use packs with different numbers of cylindrical 18650 lithium-ion cells.
This was not like WWI. Advances in tanks, bombers, fighters, meant there was less of a chance to successfully stave off a first strike. The Soviet Union held out because of the sheer size of the country. In initial phases of the invasion of the Soviet Union, the Nazis invaded many times the area of France over. The SU had to dismantle their industry in a hurry and move production behind the Urals, where the Luftwaffe could not reach them.
You seen to forget not only French but British forces withdrew from France after the Battle of Dunkirk. They took the full brunt of the Nazi military. There was no Eastern Front open at the time. The US fought a diminished Nazi force which had lost a million men in Stalingrad. The European allies problem was not invading Germany sooner, like at time time of the partition of Czechoslovakia.
Slashdot Mirror
To the point where it looks nothing like the concept car. IMO the concept looked different, while the current prototype looks like a Toyota Prius or Honda Civic.
Fried foodstuffs contain known carcinogens. We should add this informative label to potato chips as well.
No, not a good idea. What is the point in having a Cultural Revolution? Better to just split these companies which are too big to fail into smaller chunks, kick out the top management making sure they never work in that capacity anymore, enforce layers of separation between businesses and let them free. Restore the Glass–Steagall Act and separate commercial banking from investment banking.
A lot of the original X86 patents have expired and new processors are based on X86-64. AMD was the designer of X86-64 so I suppose they hold most of the patents. AMD has been quite liberal at licensing X86-64 in the past to companies such as VIA and yes, even Transmeta.
PS: NVIDIA already has a X86 CPU. When they bought ULi they got their very own 386 SoC chip. Heh.
The top two leading architecture segments in terms of $$$ are X86 and S/360, both CISC designs. ARM is supposedly RISC, but uses Thumb to compress instructions so they use less memory space.
Intel has less profit margin in their X86 processor division than IBM has in their S/390 mainframe division as well.
Even if you port Windows, you still need applications. Otherwise you are better off using a Linux distro where you can recompile the apps most people use yourself.
The first Intel "quad core" processors (Intel Core 2 Quad) came in a multi-chip module with 2 chips per module, 2 cores per chip. So if that was a 4 core, POWER 7 is 16 core.
Still, if I was the FTC, I would force Intel to do two things: license the X86 ISA and its extensions, plus the CPU bus interface to all comers in a RAND basis.
No, Intel has been the real CPU leader since Intel Core came out. They use more advanced manufacturing technology faster. They do their process shrink a year before AMD. AMD still does not use high-k metal gates in their process. AMD's CPU design is also worse in many regards. Less total cache, no macro-op, and micro-op fusion, hyperthreading, etc. Intel's processors are also 4 issue, instead of 3 issue. AMD will only fix these design deficiencies in Bulldozer.
Really? Care to share any results that support that? I'm quite sure the peak flops you can achieve on the GPU are much higher than the limited SIMD capability of the CPU.
IIRC they claim 2.5-3x times more performance using a Tesla than using the CPUs in their workstation. Ignoring load time.
SSE enables a theoretical peak performance enhancement of 4x for SIMD amenable codes (e.g. you can do 4 parallel adds using vector SSE, in the time it takes to make 1 add using scalar SSE). In practice however you usually get like 3x more performance.
Theoretical SIMD performance for the GPU is very fine and nice, but in practice the small caches in current GPUs limit performance. CPUs also often have out-of-order execution support and other hardware which is too expensive in terms of transistors to implement in a GPU.
IMO the main problem here is that the programming model for the CPU is too complex since you need to use several different ways to express parallelism (SIMD/Multicore/Cluster) to get top performance.
At least a CPU program, when it crashes, does not bring down the whole OS. Memory protection? Pah, who needs such things... After all you never make coding mistakes. Right?
It is like MS-DOS programming all over again. Except the computer takes longer to reboot.
They use a worse algorithmic complexity algorithm in the paper because it actually performs better in the GPU than the other one. This happens in CPUs in several cases as well. When was the last time you saw someone using a Fibonacci heap? Memory footprint matters and taking advantage of the CPU caches matters. The paper also says nothing about CPU SIMD optimizations, which can make a program 3x faster if applied. That would make the performance the same as for the GPU system. Note that I am being generous here and actually ignoring the program setup time when they need to copy the data to the GPU. Because if I did not the pure CPU version would probably actually be faster.
They did the same thing with Centrino. A Centrino system contained a Pentium M processor with an Intel chipset. Intel gave kickbacks to companies which used both, in order to apply for the Centrino label.
While it is true that you need to do instruction scheduling to get top notch performance for a given processor, so the code is optimized for the number of functional units, cycle time of each instruction, etc, you should not disable a code path just because the CPU processor vendor name is different from "GenuineIntel". Such optimizations as you claim are never done, because otherwise there would be no forward compatibility for compiled code even within Intel's own processor products.
If there were published standards about how CPUs connect to the mainboard, and if the mainboard's major components were made interoperable (open BIOS, SMC, all that jazz--) that would be unbundling. The bottom line here is that if these parts were interchangable -- so that you didn't have to decide on the CPU first and then the rest of the system, that would be "unbundled". That would be a more fair marketplace than what exists right now.
It used to be this case. AMD K6 processors worked in Intel Pentium motherboards and vice-versa using the Socket 7 bus interface. Then Intel switched the processor bus to GTL and refused to license it to AMD. In fact, Intel even refused to license their bus design to chipset manufacturers at a point, because they wanted to corner that market as well. Intel sued VIA Technologies for doing AGTL bus compatible Pentium III chipsets. Only after Intel's own i820 RDRAM chipset turned out to be bugged to hell, and the third party OEMs started screaming they relented.
AMD, for Athlon, licensed the Digital Alpha EV-6 bus and had to make a separate infrastructure for manufacturing chipsets and motherboards. It was an open secret at the time that Intel pressured the Taiwanese motherboard manufacturers to not make any AMD compatible motherboards for Athlon. ASUS distributed their AMD motherboards in plain white boxes, without any ASUS markings, anywhere to escape Intel's wrath.
No, it does it at run time. AMD specifically made a code patch utility that changed the binary to circumvent this Intel compiler 'feature'.
Intel Pentium II processors did not have SSE instructions either. No one asked for Intel to do additional work, just that they followed the proper way of doing it, which was no extra work at all. Intel's practice predates SSE 4 instruction development. It is known they did this even before Opteron came out.
AMD essentially dumped SSE5 for Intel AVX. There are a couple of new instructions in there, but that's basically what happened.
No it was much worse than that. There is a CPU instruction named CPUID which tells you the processor family, manufacturer, and has a set of feature flags saying which extensions (e.g. SSE, SSE 2, 3DNow) that particular processor supports. Intel's compiler enabled SSE optimizations only if the processor manufacturer string was "GenuineIntel" and the processor family number was high enough, instead of checking in the flags vector if the processor supported SSE.
GCC and PGI have support for AMD processors. AMD often used these compilers for benchmark result submissions in the past. But the Intel C++ compiler is often faster at doing benchmark results since it has more advanced static optimization support.
The question is if this will be a de Havilland Comet or a Boeing 707.
Choice is good.
There are standard sizes for rechargeable lithium ion cells. But different laptops use packs with different numbers of cylindrical 18650 lithium-ion cells.
AFAIK Adobe Acrobat Reader uses the Mozilla SpiderMonkey Javascript engine.
You seen to forget not only French but British forces withdrew from France after the Battle of Dunkirk. They took the full brunt of the Nazi military. There was no Eastern Front open at the time. The US fought a diminished Nazi force which had lost a million men in Stalingrad. The European allies problem was not invading Germany sooner, like at time time of the partition of Czechoslovakia.