Russia now selling home-grown CPUs with Transmeta-like x86 emulation
arstechnica.com
arstechnica.com
Old Elbrus was stack based outside and has a level that translated stack-based ops into RISC commands for OoO execution. Stack based instruction set was meant to reduce code size (and complexity of code generation).
New Elbruses are VLIWs and I cannot agree with that architectural decision. They claim their VLIW and compiler solve frequent stalls (a hallmark of any VLIW arch, except in DSP setting where memory is quite predictable) but numbers in benchmarks do not agree with that.
Consider this: http://www.7-cpu.com/
Elbrus with 4 threads is about 15 times as slow in compression as Intel i7 (Intel i7 3770 (Ivy Bridge)). The difference in clock speeds is about sevenfold.
7-zip compression is very memory-intensive, and access memory in rather unfriendly manner - going backwards in dictionary search and forward in comparison.
This great discrepancy means that Elbrus stalls much more heavily than i7. And rightfully so - OoO CPUs like i7 specifically designed to avoid stalls.
Other that CPU architecture decision, Elbrus as a SoC is very good.
The delay gap between 600MHz DDR memory interface for CPU with 500MHz clock is smaller than the delay gap for 3.4GHz CPU and 800MHz DDR interface. The 500MHz CPU can get away with smaller cache or less cache levels. 3.4GHz CPU cannot - there is not enough computation volume available to mask delay of several dozens of clock cycles. There is not enough computation available in 8 SPARC Tx Niagara threads for one 1.8GHz core, even with their scout thread tech (to reduce stalling thread does resolve future addresses and prefetching data when stalled). What to say about 3.4GHz CPU with only two threads per core? It certainly will stall during cache misses for random memory access with (relatively) slow DDR interface.
In short, if you reduce clock count for Intel i7 to 500 MHz, you will have: reduced pipeline length from 15-20 cycles to 5-6, proportionally to clock frequency reduction, and reduced stalling penalty for cache misses. Shorter pipeline does not do much harm in case of mispredicted branches. Shorter pipeline also means quicker computation and less stalling in Read-After-Write command chains. To sum, you will have more performance per clock cycle than in higher frequencies.
(this is why mobile processors are mostly much slower than desktop counterparts)
So, on 7Zip problem hypothetical 500MHz i7 will be faster than just 3.4GHz i7 scaled down by 34/5 factor. I think difference will be two-three fold in favor of 500MHz i7 (mostly due to shorter pipeline, partly due to less severe penalties).
This gives that hypothetical 500MHz i7 a speed of 2.5-3MIPS/MHz.
PS Reduction of pipeline from N stages to N-1 stage gives speed boost of about 1/N. E.g., I observed in simulation speed boosts of about 15%-20% when pipeline length went from 5 to 4 stages. This was in "real" clock-accurate simulation, with proper simulation of DDR memory and controller, cache and their delays. The tests were also real, like string and graphics handling/processing.
- native "Elbrus" ISA or x86 ISA,
- Ebrus ISA is VLIW, can dispatch 23 operations per cycle (33 with SIMD), in-order execution,
- it's stated that x86 code translation + register allocation is done in HW, but later they write about a software translator and full-system emulator,
- 6 ALUs (all support integer operations, 4 can do FP),
- 256 x 84-bit register file,
- hardware support for loops, including pipelining,
- some kind of module for async mem preloading,
- speculative execution and branching predicates,
- "4S" model has 4 cores,
- 800 Mhz core clock,
- 64 KB L1, 128 KB L2, 8 MB L3 (shared between cores),
- 3 DDR3-1600 interfaces, ECC support,
- 3 x 12GBytes/s inter-CPU links, support for up to 4 sockets,
- 65nm process, 380 mm^2 die size, 986e6 transistors,
- software is based on Linux 2.6.33 and Debian 5.0 with more than 3000 packages.
There are some benchmarks for older chip model "2S" (overclocked to 500MHz, 2 cores) [2,3]. FP performance is about 1-5x of Pentium M 1GHz (1 core?) depending on benchmark, integer performance is about 1x. New CPU, "4S", should be 3 times faster than "2S".
[1] http://www.elbrus.ru/arhitektura_elbrus
[2] http://www.elbrus.ru/files/535269/9f0cd8/50606f/000000/2014-...
[3] http://www.elbrus.ru/files/535269/0e0cd8/50586f/000000/2014-...
[4] http://www.mcst.ru/mikroprocessor-elbrus4s
[5] http://www.mcst.ru/mikroprocessor-elbrus4s-gotov-k-serijnomu...
--
Edit: loop pipeling, OS information
* Register rotation [1]: referenced registers inside the loop are cycled on each iteration
* Branch prediction [2]: with a dedicated loop count register, the CPU can tell with complete certainty when not to take the jump to the beginning (no mispredictions at the exit)
[1] http://www.cs.nmsu.edu/~rvinyard/itanium/register_rotation.h...
Another set of benchmarks containing an Elbrus is at http://www.7-cpu.com/ and also shows extremely good IPC efficency - it achieves 1.2 MIPS/MHz/core for compression, which is better than all the other non-x86 in that list, and somewhere between Haswell's 1.18 and Ivy Bridge's 1.24.
If they could scale this up to a newer process, they'd probably be equal to if not surpassing Intel's current x86 performance.
In theory Elbrus can dispatch 23 non-SIMD ops per cycle, it has only 6 integer units and 4 among them can do FP, so it's not clear what remaining 17 operations can do. Modern x86 CPUs have about the same number of integer/FP ALUs.
Current IPC is quite good, but it's hard to tell if core clock can be increased without lowering IPC. If ALU pipelines are short, it may be difficult to increase frequency without adding more stages. If more stages are added then pipeline flushes due to unpredicted jumps will result in heavier penalty. And it looks like Elbrus doesn't have a branch predictor at all. Pipeline stalls caused by memory access will also increase with CPU frequency. In x86 CPUs they are somewhat masked by out-of-order execution and SMT, which Elbrus doesn't have, so it should depend on memory preload instructions inserted by compiler.
PS: Intel is at 14nm and started with 65nm back in 2006. Which is not as bad as you might assume, but still far from bleeding edge.
Likely they developed a very fast, very efficient core dye. And just swapped decoders at the last minute. Its not much of a stretch that they'd develop the ARM set in parallel b/c of the high risk associated to doing anything with x86.
There was the Longsoon which had an extended MIPS64 instruction set: http://en.wikipedia.org/wiki/Loongson
The whole point is that the JIT compiler running in the CPU can make dynamic optimizations that's somewhat similar in nature to doing branch prediction and other optimizations modern CPUs do.
The native code executed by these CPUs is a poor target for static compilation. Without runtime data about which branches are taken, which memory locations are touched, etc, it is not possible to generate code that outperforms the built-in JIT or can compete with more traditional CPUs.
And besides, the JIT frontend in these chips is rather cheap in terms of power and performance.
Just read the last few years news about hardware back door and commercial pressure from technology firm having a de facto monopolistic position and you'd understand a bit more the reluctance of anyone not a direct partner of the USofA to use and rely upon technologies coming from them.
And energy independence is not so much about avoiding having to deal with those countries you are mentioning (however you want to characterize them), but not having to be chained to their pricing policies since their are acting like a cartel. This has been the issue since the initial petrol crisis from the early '70s.
Also, the propreties that they are getting feel like being knocked back a decade--is it due to the fabrication facilities that they have?
> Also, the propreties that they are getting feel like being knocked back a decade--is it due to the fabrication facilities that they have?
Most likely. Top of the line stuff needs a lot of money and expertise -- Russian companies don't have that much of the former, and Russia exports or rent^H^H^H^H uses a lot of the latter for outsourcing.
http://wccftech.com/arm-baikal-processor-8-cores-cleansweep-...
Not sure what MCST's ties are to the government.
If they made kernel changes, and choose to respect GPL, I'd be interested to see those sources...
There are no links to sources on their site, and they don't provide datasheets. To request sources under GPL you need to get binaries first. I live in Russia, and I've never seen Elbrus in real use anywhere. It's not marketed or sold to general public. I think target market is government's security agencies. Of course they get sources anyway for audit and have no incentive to publish them.
[1] (russian) http://www.mcst.ru/os_elbrus
This is a common misconception, at least as far as GPLv2 goes. If you're distributing commercially then you have two choices:
1) Include the source when you distribute the binaries (GPLv2 3(a)) 2) Offer the source code on demand to any third party (GPLv2 3(b))
Of course, Elbrus may be distributing under the first of these, but if it's the second then there's no need to obtain binaries in order to make a request for source.
Company I work for once tried to get linux kernel sources for an embedded system produced by another russian company. We got just honest "we have our proprietary module in our linux tree, so we won't be giving you any sources. Still, we are nice enough to recompile it for you with options you need." Ugh...
The libelpthread caught my eye -- a "version of libpthread, optimized for operation in hard real time" (according to bing translator). And there's a paper in English about this: http://www.mcst.ru/doc/1107/PCS223.pdf
They also state that in realtime mode it's possible to set up different modes of external interrupt handling, "computation scheduling", "disk i/o" and "some other things", whatever that might mean. Kernel is modified to support realtime operation too.
I miss the Alphas. Those machines were _awesome_.
Imaginary example:
mul 37 -1
Could be automatically identified and replaced with a predetermined codestream of:
add (not 37) 1
This allows super complicated instructions (of which x86 has many) to be implemented with simple instructions, and it also allows the designer to work around bugs that might be discovered later on.
As a technical term, microcode is contents of memory that is used to implement CPU sequencing (in contrast to doing sequencing in hardwired random logic or having essentially no sequencing logic as is the case in classical RISC designs). In most straightforward implementation it's essentially turing machine with microcode as state table and tape replaced by rest of the CPU. Various enhancements and modifications are possible which end in having essentially full-blown CPU for processing microcode, but even in that case one thing is critical for the term: the microcode only handles control functions (sequencing) and does not directly process data.
Heck with "720/1080p" screens becoming popular there was actually quite a decrease in the overall resolution in laptop screens between say 2005 to 2012 with 720 and 800/900 vertical resolutions screens being produced instead of the good old 1000+ vertical resolution screens we had previously.
I didn't want to upgrade a laptop for almost 2 years because i wouldn't use a screen with so little vertical real estate, now with 1440-2160p screens becoming popular again it's a very good time indeed. And I hope that 3:2 screens actually catch up, I've been using a 1440x1440 screens now for some months now and the square format is just amazing for productivity, nothing is outside of your focus and they are just awesome for half screen vertical tiling.
Most everything else has been bundles of hardware accelerated instructions for performance gains on popular data classes (see: MMX, AVX256, etc).
It's rare you run into software that doesn't have multiple codepaths, leveraging an extension if you have it and bypassing it if you don't.
Extensions that you are defacto required to have are so old, you almost certainly have them anyway. MMX was introduced in 1997 in the P5. MMX support will not be the first problem on your list if you're trying to run modern software on a P4.
Does anyone have any idea why an average consumer, would even consider buying this at this price?
I can imagine that quite a few companies outside the US are going to build some of their core IT around this CPU. The CPU price is quite low if you consider what the data is worth.
For people that want to swap KGB surveillance over NSA's.
FTFY
Say you're in the west. NSA has backdoors into your US-designed hardware and your US-designed OS. NSA also, probably, has access to your ISP's routers and US net/web corporations like Google. As a result, NSA may hide C&C channels where KGB use of a backdoor to your hardware would still show detectable illegitimate network traffic.
Lower risk of detection translates to higher probability of use.
Because we are will be open-sourced soon and in russia there is there own smartphones (but build in china yes) we can try to provide most secure solution in market.
May be some countries like Germany are interested in such things.
PS. I didn't know that actually, just followed few links from the Elbrus Wikipedia page and bumped into an interview with the MCST founder from 2003 [1] - he basically says there that in the early 90s there was a spike of interest in the tech behind Elbrus 3. First it was HP, then it was Ditzel, who was at that time with Sun. Ditzel eventually quit Sun and went on to found Transmeta and develop the Crusoe. Babayan then goes on to say that "We are effectively on a market, except we are not seeing any money. But on the other hand without Ditzel we would've not gotten any (research) money and all our work would've died." Interesting stuff.