Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Tuesday September 25 2018, @12:05AM   Printer-friendly
from the competition++ dept.

Zhaoxin Displays x86-Compatible KaiXian KX-6000: 8 Cores, 3 GHz, 16 nm FinFET

Zhaoxin, a joint venture between Via Technologies and the Chinese government, this week for the first time displayed its upcoming x86-compatible CPU, the KaiXian KX-6000. The SoC features eight cores running at 3 GHz and increases performance over its predecessor by at least 50%.

The KaiXian KX-6000 is a successor to the KX-5000 CPU launched earlier this year. Both chips integrate eight-core x86-64 cores with 8 MB of L2 cache, a DirectX 11.1-capable iGPU with an up-to-date display controller, a dual-channel DDR4-3200 memory controller, contemporary I/O interfaces (PCIe, SATA, USB, etc), and so on. The key differences between the KaiXian KX-5000 and the KaiXian KX-6000 are frequencies and manufacturing technology: the former is produced using TSMC's 28 nm fabrication process and runs at up to 2 GHz, whereas the latter is made using TSMC's 16 nm technology and operates at up to 3 GHz. Zhaoxin claims that the Kaixian KX-6000 offers compute performance comparable to that of Intel's 7th Generation Core i5 processor, which is a quad-core non-Hyper-Threaded CPU. Obviously, performance claims like that have to be verified, yet a 50% performance bump over the direct predecessor already seems beefy enough.

Related: Russia Plans to Dump Some American CPUs for Homegrown Technology
Russian Homegrown Elbrus-4C CPU Released
U.S. Export Restrictions Lead to Chinese Homegrown Supercomputing Chips
Linux-Based, MIPS-Powered Russian All-in-One PC Launched
China Dominates TOP500 List, Leads With New 93 Petaflops Supercomputer
Chinese Company Produces Chips Closely Based on AMD's Zen Microarchitecture


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by bob_super on Tuesday September 25 2018, @04:11PM (2 children)

    by bob_super (1357) on Tuesday September 25 2018, @04:11PM (#739736)

    We make an FPGA-based NAT/Firewall. Not at the kind of prices you guys would like to pay, but I should really look into a cost-reduced version.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 0) by Anonymous Coward on Wednesday September 26 2018, @04:57PM (1 child)

    by Anonymous Coward on Wednesday September 26 2018, @04:57PM (#740311)

    That sounds interesting. How does it work?

    • (Score: 2) by bob_super on Thursday September 27 2018, @04:15PM

      by bob_super (1357) on Thursday September 27 2018, @04:15PM (#740842)

      Open every packet at the 10G line rate, check that the headers match exactly what is allowed in, check length and CRCs and a few mandatory fields, potentially replace the headers on the way out the other side. Works mostly at layer 3-4, but it can allow or reject pretty much any packet as long as you program the header in.

      It's for professionals with stable flows. Having it dynamically adjust to the hundreds of IPs that your browser wants to connect to for every click you make would be a good deal more annoying. But I know for a fact that nothing that isn't explicitly allowed can get through. There is no "zero day in some sub-library" when you write your own HDL to do bitwise comparisons. Someone would have to hack the controlling computer and add their traffic to the list, or maskerade as legit traffic up to layer n+1 and break the system using higher layers, which would still not allow to expand to new connection or ports until they go to add those new connections to the authorized list.

      A Gig-E version would be simpler and considerably cheaper. The main difficulty is to write the control software to allow the right connections in real-time and close them right after. Professional orchestration used by our mostly-staticly-routed customers is very expensive.