From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:764f:: with SMTP id z76-v6mr2395653itb.11.1524259017660; Fri, 20 Apr 2018 14:16:57 -0700 (PDT) X-Received: by 2002:a9d:2044:: with SMTP id n62-v6mr180664ota.4.1524259017509; Fri, 20 Apr 2018 14:16:57 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!f63-v6no1221874itc.0!news-out.google.com!u64-v6ni2176itb.0!nntp.google.com!k65-v6no1211942ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 20 Apr 2018 14:16:57 -0700 (PDT) In-Reply-To: <87zi1xu0xg.fsf@nightsong.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.233.194; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.233.194 References: <1c73f159-eae4-4ae7-a348-03964b007197@googlegroups.com> <878t9nemrl.fsf@nightsong.com> <87h8o7lowg.fsf@nightsong.com> <8736zqkwat.fsf@nightsong.com> <6839088c-f221-4650-a6ea-1841ae539486@googlegroups.com> <87zi1xu0xg.fsf@nightsong.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <77f91974-526f-49f2-ab9f-9f0f3ef36982@googlegroups.com> Subject: =?UTF-8?B?UmU6IEhvdyB0byBnZXQgQWRhIHRvIOKAnGNyb3NzIHRoZSBjaGFzbeKAnT8=?= From: "Dan'l Miller" Injection-Date: Fri, 20 Apr 2018 21:16:57 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:51650 Date: 2018-04-20T14:16:57-07:00 List-Id: On Friday, April 20, 2018 at 2:34:39 PM UTC-5, Paul Rubin wrote: > "Dan'l Miller" writes: > > Embedded realtime systems are going to be going mainstream in data > > processing with FPGAs in the datacenter. >=20 > Hmm. FPGAs in the datacenter are usually about doing specialized > computation efficiently: examples include things like machine learning > using the DSP blocks on the FPGA's, or (famously) bitcoin mining. > So I wouldn't count that as either realtime or embedded. The functionality formerly of network processors is moving to many-core gen= eral-purpose processors (with or without accompanying FPGA) in data-centers= . https://en.wikipedia.org/wiki/Data_Plane_Development_Kit#Projects =E2=80=9CWe have a goal of being able to forward, with packet filtering at = rates of at least 14.88Mpps*. This is 'line rate' on a 10Gbps interface. Th= ere is simply no way to use today's FreeBSD (or linux) in-kernel stacks for= this type of load.=E2=80=9D [but now with DPDK that is within reach] * mega-packets per second in the hard-realtime unit of measure commonplace = on network processors (NPs) Believe me, sustained fiber-optic line-rate 10Gbps packet processing is har= d realtime (which is a little dubious with Linux instead of bare-metal, but= hey, anything that cracks the hard-realtime whip to get Linux to nearer an= d nearer to being an RTOS is welcome!). With proper software design, imagine a 1024GiB-DRAM ccNUMA multi-socket con= federation of, say, many-core Intel Xeon processors with HyperTransport bet= ween them with proper processor affinity meticulously assigned, so that one= or two of the Xeons are doing DPDK line-rate processing one or two(-duple-= redundant) fiber-optic lines and then feeding slower-rate events (e.g., PIP= multicast-topology-change requests) to other Xeons running routing softwar= e on general-purpose processors. Now imagine instead of that application s= upporting multicast video at, say, a cable-TV network, instead this same ar= chitecture is re-targeted for other protocols in the protocol-stack, such a= s sophisticated serving of traditionally software-speed content on the WWW = now at line rate. Now imagine the death of dynamically interpreted scripti= ng languages on the WWW servers, favoring vast stores of pre-computed** pur= e-HTML5-page content served at line-rate by this hardware & DPDK architectu= re. We in telecom have been laying the groundwork for this for a decade. = It is now coming more & more into full fruition. Intel's $16 billion purch= ase of Altera was a happy surprise accelerant to our SDN/NFV vision of migr= ating the network processing out of the telecom central office to the enter= prise data center. Just as you no longer expect the telephone to be dumb 1= 930s-era-technology PSTN POTS 4-wire or 2-wire analog device with all the s= marts in a Lucent 5ESS telephone switch at the telecom central office (repl= aced by intelligent devices: smart phones and wireline VoIP), in the near = future the same type of displacement revolution will occur to today's era o= f turtle-speed WWW servers in the enterprise: replace slow interpreted-lan= guage WWW servers with line-rate WWW/anti-DDOS servers. By, say, 2025, 10G= b/s line-rate servers will be the norm. Whichever language facilitates it,= will dominate line-rate WWW/anti-DDOS servers & security-enforcement serve= rs in the enterprise data centers for a decade or two. Right now Ada shoul= d have had the lead when measured by long-standing language features in sup= port of this vision, C++17 has the momentum, and Rust is the potential wild= -card disruptor. ** pre-computed at the relatively slow rate of product-inventory management= of a product in, say, an SQL database at, say, a retailer's website (The cloud will bifurcate into 2 services: nonrealtime data-processing and= realtime line-rate WWW/anti-DDOS servers.)