Slashdot Mirror

You mean like this 18 core Xeon? http://ark.intel.com/products/...

Problem with VLIW was that each new CPU was guaranteed to break backwards compatibility,

Only if you do it in a way that either 1) changes the instruction encoding from CPU to CPU or 2) doesn't have rules for code that's guaranteed to work on all future processors. The IA-64 documentation gives the instruction encoding for all processors, and does have rules of that sort (see, for example, section 3.4 "Instruction Sequencing Considerations"), so they didn't do it in one of those ways, so each CPU is guaranteed not to break backwards compatibility for valid code (which means that the code doesn't, for example, have any of the dependencies that are "not allowed" by section 3.4).

That actually assumes that Intel can't add new instructions to future versions of the Itanium that may not have been anticipated during the work on Merced. I wasn't assuming that opcodes would change, just that new ones would be introduced that might improve, say, loop unrolling, and that to make use of that, the VLIW compiler would have to kick in. Like if the number of registers in a subsequent generation CPUs is increased, and register renaming is in the hands of the compiler, recompilation would automatically be required to get any performance enhancement, or worse, prevent a performance degradation.

That's a bit more than what happens with every other type of CPU, but not all that much more - new instructions are added, and some instruction sets even acquired more registers (z/Architecture added some instructions to manipulate the lower half and upper half of registers, so that a single 64-bit GPR can act as 2 32-bit GPRs, for example).

But that doesn't break binary compatibility, it just requires recompilation for more performance. If not recompiling causes a significant performance hit, that's a severe problem, though.

(And the recompilation would happen transparently, other than some first-time performance hit, on a {System/38,AS/400,IBM i}-style system, where compilers generate a higher-level code that gets translated to executable machine code when the code is first executed, allowing a re-translation the first time the code is executed on a new machine. That's also kinda sorta what Transmeta did. But most systems aren't like that, for better or worse.)

What finally killed both RISC and EPIC was not x86 itself, but the multi core architecture that Intel packed into its way advanced processes. Once Microsoft united the Windows code bases in XP, making SMP support standard on all Windows, Intel could toss in more cores to boost performance, and totally negate the performance advantages of the PA-RISC, Alpha and everyone else.

I had the impression that, at least for the desktop and small server market, they lost a lot of that performance advantage well before Intel went multi-core.

That might have been the case with the Pentium 4, but then it had some serious issues, such as power consumption, that hampered its market acceptance.

I seem to remember seeing claims (in Microprocessor Report?) that x86 was giving the faster RISCs a run for their money in the P6 days, even if it wasn't quite doing completely as well or better.

Problem with VLIW was that each new CPU was guaranteed to break backwards compatibility,

Only if you do it in a way that either 1) changes the instruction encoding from CPU to CPU or 2) doesn't have rules for code that's guaranteed to work on all future processors. The IA-64 documentation gives the instruction encoding for all processors, and does have rules of that sort (see, for example, section 3.4 "Instruction Sequencing Considerations"), so they didn't do it in one of those ways, so each CPU is guaranteed not to break backwards compatibility for valid code (which means that the code doesn't, for example, have any of the dependencies that are "not allowed" by section 3.4).

That actually assumes that Intel can't add new instructions to future versions of the Itanium that may not have been anticipated during the work on Merced. I wasn't assuming that opcodes would change, just that new ones would be introduced that might improve, say, loop unrolling, and that to make use of that, the VLIW compiler would have to kick in. Like if the number of registers in a subsequent generation CPUs is increased, and register renaming is in the hands of the compiler, recompilation would automatically be required to get any performance enhancement, or worse, prevent a performance degradation.

Of course, today's Itanium - the Itanium II or III, I've lost track - is more a RISC CPU than even an EPIC - things like register renaming, once the job of the VLIW compiler, is now there on silicon itself, just as it was with the RISC CPUs

therefore forcing ISVs to recompile every time. Great for performance, maybe, but horrendous as a market acceptance strategy.

Except that you don't have to recompile code to have it run on a future Itanium processor, as long as the compiler wasn't "too clever", generating code with "not allowed" dependencies because it "knew" that the processor would execute that code in the way it intended.

You might get performance improvements by recompiling for a new processor, but that's hardly unique to Itanium.

Yeah, I wasn't thinking so much about performance improvements, as much as recompiling to make use of more pipelines, or so on. Of course, one could squeeze all the parallelism out of the code right at the get-go by making it independent of the number of functional units of the CPU, and make that question moot.

What finally killed both RISC and EPIC was not x86 itself, but the multi core architecture that Intel packed into its way advanced processes. Once Microsoft united the Windows code bases in XP, making SMP support standard on all Windows, Intel could toss in more cores to boost performance, and totally negate the performance advantages of the PA-RISC, Alpha and everyone else.

I had the impression that, at least for the desktop and small server market, they lost a lot of that performance advantage well before Intel went multi-core.

That might have been the case with the Pentium 4, but then it had some serious issues, such as power consumption, that hampered its market acceptance.

Problem with VLIW was that each new CPU was guaranteed to break backwards compatibility,

Only if you do it in a way that either 1) changes the instruction encoding from CPU to CPU or 2) doesn't have rules for code that's guaranteed to work on all future processors. The IA-64 documentation gives the instruction encoding for all processors, and does have rules of that sort (see, for example, section 3.4 "Instruction Sequencing Considerations"), so they didn't do it in one of those ways, so each CPU is guaranteed not to break backwards compatibility for valid code (which means that the code doesn't, for example, have any of the dependencies that are "not allowed" by section 3.4).

therefore forcing ISVs to recompile every time. Great for performance, maybe, but horrendous as a market acceptance strategy.

Except that you don't have to recompile code to have it run on a future Itanium processor, as long as the compiler wasn't "too clever", generating code with "not allowed" dependencies because it "knew" that the processor would execute that code in the way it intended.

You might get performance improvements by recompiling for a new processor, but that's hardly unique to Itanium.

What finally killed both RISC and EPIC was not x86 itself, but the multi core architecture that Intel packed into its way advanced processes. Once Microsoft united the Windows code bases in XP, making SMP support standard on all Windows, Intel could toss in more cores to boost performance, and totally negate the performance advantages of the PA-RISC, Alpha and everyone else.

I had the impression that, at least for the desktop and small server market, they lost a lot of that performance advantage well before Intel went multi-core.

If so, could you cite some papers indicating that, for example, the SPARC M7, or the POWER8, or the Itanium 9500, have microcode in that sense?

It probably does not apply to SPARC, I am fairly certain that there is microcode involved at minimum in some POWER processor coprocessors but can't find a reference, there is absolutely microcode in Itanium and Intel has used it to fix errors.

There's firmware , but it's not clear from what Intel says there that it's "microcode" in the conventional sense, as opposed to low-level Itanium instruction set (the instruction set formerly known as IA-64) code.

The flat-out refusal to have kernel level generic usb3 driver means that all hypervisors running on Win7 must either have their own full USB3 implementation or be limited to USB2.

Can't you use the Intel Win7 driver? worked for me with Win7 inside VirtualBox. Think this is the link:
Here

Two easily refutable arguments? Why so vague? What are they? Are you saying with absolute certainty that every single person running win7 has usb3, that you have not a single doubt in your heart or mind? How do you know this with such conviction? As for usb3 drivers that's a lot easier to prove. Don't really know why you're arguing against it when a quick google search can prove it.

https://downloadcenter.intel.c...

Of course that's assuming those are the two easily refutable arguments you were talking about. I don't really know since you didn't say. Maybe instead of speaking in riddles you could get to the point.

"Intel was caught napping by the mobile revolution, and they were late to the party. Thanks to iPhone and Android devices, ARM is the standard for mobile."

Full disclosure: I was an Intel employee.

Actually, Intel was ready to throw it's own party.. Remember XScale - Intel's implementation of the Arm V5 Architecture? Which they later sold to Marvell back in 2006 because it didn't fit into their core x86 product line. A spectacularly stupid move.

As for IoT, Intel was ahead of that game as well, they had a microcontroller division that manufactured the MCS51 (8-bit CISC), MCS196 (16-bit CISC), and i960 (32-bit RISC) product lines that could have evolved into IoT-centric devices. But they cash cow'ed that division in 1997, not because it was unprofitable, but because it wasn't profitable ENOUGH. They exited microcontrollers in 2006. Now they're trying to play catch-up. Spectacularly stupid move #2.

For all their talk about 3-year, 5-year and 10-year plans, They really blew it on this.

"Intel's business model is to make chips that you need, that you can only get from Intel, and then charge a very profitable margin on those chips. Intel does not want to compete on price in a commodity market".

This, 1000x this. The problem also is that they didn't realize, or want to recognize, that the market for PCs would eventually become saturated with "good enough" machines and the CPU would be a commodity part. Their focus (tunnel-vision?) on CPUs is how they got here today.

Core-M should serve this market well:
http://ark.intel.com/products/...

Several of the chips in the 2ghz range are passively cooled.

no ECC memory support

O, rly?

"The chip maker also plans to focus on chips and technologies for IoT devices"

Before connecting 'things' to the Internet, how about fixing the defective MMU that comes in most WinTEL personal computers.

http://ark.intel.com/products/... The only virt this doesnt support is VT-d. I have spent the last few years exploring Intel's bottom line of processors, from NUCs to tablets, they are solid. Times have changed. Like i said above, i built a machine out of AMD's newest low power platform (AM1), i wasnt impressed relative to intel.

We had a thread about them a month ago, but here you go.

My feeling is that thing is going to spend a lot of time throttling because of poor thermal design since that's what the i3 and i5 NUCs have done throughout their history, but that thing is a legitimate quad-core machine.

I'm not sure what the article submitter is smoking. According to this: http://www.everymac.com/system... the current Macbook Air has a "Core i7 (I7-5650U)" processor which per Intel's own website http://ark.intel.com/products/... debuted in Q1 2015.

bare metal really matter all that much any more

Yes, it does. There are still hardware level functions that VMs will pass through for efficiency, e.g., 3d rendering via hardware graphics. Unless you're talking about QEMU level virtualization, VMs will still use the hardware to the extent possible. Intel has capabilities built into it's architectures to support these things. http://www.intel.com/content/w...

Or put a Linux distro on your device (maybe even move that Windows stuff to a VM and disable network if the apps don't need it).

I already have the latest Skylake chip-set for my desktop and Fedora 23 runs on it without any issue. I have even got Mint running in a virtual machine and again no issues. When you look at the BIOS boot it lists Windows 7 onwards however I just selected "Other OS" and I had no issues installing Fedora 23 which took less than 30 minutes.

Since I am not into over-clocking I chose the basic 4 Core i7-6700 which has a maximum power rating of about 65W and a GA-Z170M-D3H motherboard with 16GB of DDR4 RAM. This is by no means top of the line however even though the clock frequency is rated at 3.4GHz to 4GHz Turbo. See the following info . When my desktop is idle or I am only doing some simple web surfing the clock frequency is about 800MHz and can ramp up to 4GHz depending on what you are doing and this is the default after the sixth motherboard update.

What is interesting is that my desktop (including everything) when idle to simple web surfing consumes less than 40W when I just use the inbuilt graphics of the motherboard and the most power consumption I have seen is 140W when doing some video translation. Of course once you start using one or more graphics cards then power usage will increase enormously.

Personally I don't care what Microsoft tries to dictate I am very comfortable with Linux and like you have said if I really need a Microsoft OS I can run it in a virtual machine although when that happens be prepared for Hell freezing over. :-)

Intel's take on it.

Whilst not authoritative, it is a pretty good explanation between the Workstation & PC. Apple would seem to agree with me, since their workstations have Xeons in them.

The PM1633a sports random read/write speeds of up to 200,000 and 32,000 IOPS.

Those are rather lopsided performance spec's - random reads more than six times as fast as random writes. There are much smaller SSD's that offer random read/write speeds of 460,000 and 290,000 IOPS, for example.

For some applications the larger, slower SSD's may be fine, but for database applications those random write spec's are pretty lacklustre.

Try an Intel NUC. I use the latest 14nm version with OpenElec/XBMC installed as my everyday HTPC. I even used a 2 GB stick of ram to keep costs low. I boot mine off the SD card slot, because i dont have a lot of card access beside boot up. You have sata and m.2 inside if you want it.

This particular NUC
http://www.amazon.com/Intel-NU...
is the dividing line between x86-64 and ARM at the low power end. Compared to the Pi, its expensive, but its robust feature set makes up for it. I use and recommend both NUCs and Pis. The NUC5 series even has GPIO.

http://www.intel.com/content/w...

Pentium, 2015 model, with ECC.

http://ark.intel.com/products/...

From what I've read about AMD's Zen architecture, they've dispensed with the "two single threaded cores per module" architecture and now have SMT allowing two threads in each core according to this, much like "hyper threading" on Intel chips.

If that's the case, and we can expect a 32 core chip to execute 64 threads, then that's an awful lot of threads to keep supplied with data and instructions. In comparison, the biggest Intel Xeon I know about, the E5-2699 v3 has 18 cores, 36 threads, 45MB of last level cache, and 4 memory channels (68GB/sec to RAM). Intel sticks pretty close to that 1.25MB cache per core in their big Xeons. So if you adhered to Intel's apparent rules, a 32 core 64 thread chip would need 80MB of LLC and maybe 6 memory channels. Anandtech estimates 5.7 billion transistors for the big Xeon. Scaling the Intel design from 18 to 32 cores would require over 10 billion transistors! That number leads me to believe that an SMT 32 core 64 thread chip built with 2016 technology would not be practical.

What might be practical is a chip with some "heavy" cores optimized for balls-to-the-wall floating point execution, and other "lighter" cores for lower power integer tasks. This has been done in "octocore" mobile phone chips and called a big LITTLE architecture. The idea is that the OS and various decoding and checksumming tasks can stay resident on the low power light cores, while the heavy cores do things like game physics and photo noise reduction. Because the multiprocessing is not symmetric, the OS kernel needs special rules to assign tasks to cores. Which leads me to wonder if AMD has something like big LITTLE up its sleeve for 32 core Zens.

How many phones have Intel chips?

Five.

Not that UEFI isn't catastrophically broken, but reading TFA, in this case the real problem seems to be the way it is implemented on some motherboards (TFA mentions "some MSI notebooks" without specifying further)

The problem is UEFI is so complex that many manufacturers make a lousy implementation with a lot of copy-paste code (from Intel's reference implementation). Their QA process seems to be something like, "Does Windows boot? If it does, then it must be ok."

Of course, manufacturers should be blamed for their mistakes, but if UEFI were simpler, there would be less room for mistakes.

Is it 64-bit?...

The processor is 64-bit, I don't know about the rest of it. http://ark.intel.com/products/...

But is it 64-bit like the Atari Jaguar video game console and the AMD Jaguar processor (used in PlayStation 4 and Xbox One video game consoles)?

The article repeatedly says "x86", not "x86-64", "x64", "AMD64", or "EM64T", yet it mentions "Intel Atom Z3735G (Bay Trail)" which Intel says is 64-bit. But does its firmware support 64-bit mode?

- General overview
- Implementation and Reference Guide

- General overview
- Implementation and Reference Guide

>> Intel uses unencrypted HTTP connections to check for driver updates.

What a bunch of dumbasses! It's a good thing no one buys security from Intel!

>> http://www.intelsecurity.com/
>> http://www.intel.com/content/w...

(quits laughing, starts crying)

Intel has just acknowledged a bug in their Skylake CPU's that surfaces when calculating prime numbers. Prime numbers happen to be heavily used in crypto. Is this a genuine bug, or a microcode backdoor-gone-rogue that can be exploited by some agencies?
https://communities.intel.com/...

So are you never going to buy an Intel product again?

Go see page 21 for example:
http://www.intel.com/content/d...

A lot of difference.

The only difference I can see is that I'm right and you're wrong. Deal with it, kid. If you don't like the previous options then use Java or Ruby or whatever language you like that provides a toolchain to target iOS.

Optimization Notice

Intel’s compiler may or may not optimize to the same degree for non-Intel microprocessors for optimisations that are not unique to Intel microprocessors. These optimisations include SSE2, SSE3, and SSSE3 instruction sets and other optimisations. Intel does not guarantee the availability, functionality, or effectiveness of any optimisation on microprocessors not manufactured by Intel. Microprocessor-dependant optimisations in this product are intended for use with Intel microprocessors. Certain optimisations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.

Notice revision #20110804

As written by Intel, but written in text for the convenience of visually impaired slash-dotters with screen readers. Highlights mine.

The article is repeating a lie. The actual settlement and case do not contain the lie.

The Lie is Intel sold below cost.

Due to a fixed cost to operate a fab and process wafers, the cost per die is greatly impacted by line yield.

Due to the competitors line yield of about 50% at the time, it was assumed Intel had to be selling below cost. This was investigated and found to be false based on the number of raw wafers purchased and the number of die shipped. If two identical companies manufacture identical chips and one has 45% yield and the other 90% yield and offers bulk discounts that is 20% below the other companies cost to produce, it does in no way indicate the company is selling below cost. Read the lawsuit and settlement.

Intel agreed to change some business practices and settled, but still claimed they did nothing wrong such as dumping below cost, because they were not.

The cost per die was calculated based on the number of wafers purchased and the number of die shipped. Intel had much higher line yield than AMD.

AMD cut corners trying to compete, but did not solve the yield issue. AMD on the other hand had a policy of undercutting Intel on Price, but with their lower yield, they ran into the problem of having to sell below cost to meet their price points. This is where the incorrect assumption was made that Intel had to be selling below cost. This has been proven otherwise.

http://www.cnet.com/news/intel...
http://www.intel.com/pressroom...
"By contrast, AMD's investments in manufacturing capacity during this period were anaemic - because AMD had elected to change course. Through the late 1990s, AMD itself has acknowledged, AMD had persistent quality problems with manufacturing production and insufficient capacity."

Please do not repeat the lie that Intel sold under cost. They didn't. They had lower production costs due to higher yield.

Intel's compilers still use the CPUID instruction to decide whether to emit efficient code or not. Intel has an official notice to this effect. Charmingly, the notice is only available as an image file. I presume this is to make it harder to search for the notice.

https://software.intel.com/en-us/articles/optimization-notice/

Every time I see benchmarks now, I wonder whether the results were affected by the use of an Intel compiler.

I try very hard to not buy Intel products.

"The Pi Zero had an average power consumption of 2.7 Watts and the Raspberry Pi 2 was at 3.5 Watts";
Ok then compare that with a 3W Intel Atom E3805 if you want a modern performance per watt metric. Guess what the outcome will be?

Or if you want to use passive or liquid cooling

Intel produce liquid coolers too: http://www.intel.com/support/processors/sb/CS-034340.htm

"unlocked" not "overclocked"...it has the potential to be overclocked. Per Intel's own page

The K's can be overclocked, they don't ship that way though. I just bought an I7-2600K retail, and it was the blue box and also included the standard Intel fan. Intel's page here describes what all their codes mean.

Not quite.

+1

Despite what a lot of Pi enthusiasts seem to think, the Pi is not the solution to every problem. Even apart from the sluggishness of a Pi browser, a little forethought here can determine a lot of potential applications that the Pi is definitely not suitable for in this context.

Intel documents triple display setups with its little NUC boxes, and a few of those would be a much more flexible solution.

Adding displays via USB DisplayLink adapters is also an option; I run a third monitor via a DisplayLink adaptor, and performance is almost indistinguishable from a native monitor (and that's a USB 2 adapter, not USB 3). I'm not sure how adding additional DisplayLink adapters scales though.

i3, i5, and i7 represent "good", "better", and "best" respectively. That's it. A *particular* SKU with an i5 mark may have 4 physical cores, but 4 physical cores is not a requirement to receive the mark.
For example, this i5 has 4 physical cores: http://ark.intel.com/products/... while this i5 has 2 physical cores http://ark.intel.com/products/...

i3, i5, and i7 represent "good", "better", and "best" respectively. That's it. A *particular* SKU with an i5 mark may have 4 physical cores, but 4 physical cores is not a requirement to receive the mark.
For example, this i5 has 4 physical cores: http://ark.intel.com/products/... while this i5 has 2 physical cores http://ark.intel.com/products/...

I used to think that too, but then I learned assemblers and even machine code can have bugs. Now I write all my software on the cloud!

You can get an Intel HDMI Compute Stick with way much better specs at nearly similar price point.

On intel's compute stick page ( https://www-ssl.intel.com/cont... ) it only lists one processor configuration, the Atom Z3735F. That CPU scores 905 of the Passmark CPU benchmark (cpubenchmark.net)

By comparison, the the Kangaroo uses a x5-z8500 processsor, which scores 1,652 on the same tests.

If anything, the kangaroo has almost twice the processing power of the compute stick.

But why would you need the battery (just one more thing to swell up and explode) and why would you want all that bulk when you could just get one of these?

Err - no.
http://ark.intel.com/products/... - 18 core.
" a 36 total core dual E5-2699v3 we see performance 29x to 51x that of llvmpipe"
Two processors, with 18 cores each.

Lol, no way. It's not unified. It's just kinda whatever.

"Graphics drivers for 2nd Generation Intel® Core Processors with Intel® HD Graphics 3000/2000, are not supported for Windows10*"
https://communities.intel.com/...

It's arbitrary what they support where. Nothing is ever compatible, or they would have one file labelled "driver", not a million ones for each different iteration in the first place.

My server spec's likely won't be helpful for you. One of the SSD's alone would pretty much use up your budget. Here are the details anyway:

Intel S2600CP Motherboard
2 of E5-2620 v2 @ 2.10GHz
64GB of DDR3L 1600MHz RAM
1000W Power Supply
Intel RMS25KB040 RAID Controller
AXXCBL740MS7P RAID/SAS Cable Kit
2 of 500GB SATA HDD in RAID1 for OS/Boot
2 of Intel 750 Series PCIe 1.2TB SSD for VM storage

Software installed includes:
VMware ESXi 6.0.0
Intel-nvme-1.0e.1.1-1OEM.550.0.0.1391871.x86_64.vib
Scsi-mpt2sas-20.00.00.00.1vmw-1OEM.550.0.0.1331820.x86_64.vib
Vmware-esx-provider-lsiprovider.vib

My server spec's likely won't be helpful for you. One of the SSD's alone would pretty much use up your budget. Here are the details anyway:

Intel S2600CP Motherboard
2 of E5-2620 v2 @ 2.10GHz
64GB of DDR3L 1600MHz RAM
1000W Power Supply
Intel RMS25KB040 RAID Controller
AXXCBL740MS7P RAID/SAS Cable Kit
2 of 500GB SATA HDD in RAID1 for OS/Boot
2 of Intel 750 Series PCIe 1.2TB SSD for VM storage

Software installed includes:
VMware ESXi 6.0.0
Intel-nvme-1.0e.1.1-1OEM.550.0.0.1391871.x86_64.vib
Scsi-mpt2sas-20.00.00.00.1vmw-1OEM.550.0.0.1331820.x86_64.vib
Vmware-esx-provider-lsiprovider.vib

My server spec's likely won't be helpful for you. One of the SSD's alone would pretty much use up your budget. Here are the details anyway:

Intel S2600CP Motherboard
2 of E5-2620 v2 @ 2.10GHz
64GB of DDR3L 1600MHz RAM
1000W Power Supply
Intel RMS25KB040 RAID Controller
AXXCBL740MS7P RAID/SAS Cable Kit
2 of 500GB SATA HDD in RAID1 for OS/Boot
2 of Intel 750 Series PCIe 1.2TB SSD for VM storage

Software installed includes:
VMware ESXi 6.0.0
Intel-nvme-1.0e.1.1-1OEM.550.0.0.1391871.x86_64.vib
Scsi-mpt2sas-20.00.00.00.1vmw-1OEM.550.0.0.1331820.x86_64.vib
Vmware-esx-provider-lsiprovider.vib