Re: Larrabee details: Yes, it is based on the Pentium. :-)

In article <g61gpp$7cq$1@xxxxxxxxxxxxxxxxxxxx>,
Nick Maclaren <nmm1@xxxxxxxxxxxxx> wrote:

In article <v5cq5g.7002.ln@xxxxxxxxxxxxxxxxx>,
Morten Reistad <first@xxxxxxxxx> writes:
|> In article <e63aa4b5-b086-4172-8cdc-0d8364206840@xxxxxxxxxxxxxxxxxxxxxxxxxx>,
|> Robert Myers <rbmyersusa@xxxxxxxxx> wrote:
|>
|> >The question here is how many applications will be found for hundreds
|> >of cores, and is there an equivalent of Visi-Calc for this
|> >architecture. Are we looking at a paradigm shift, or just a temporary
|> >diversion?
|>
|> All the realtime multimedia stuff needs tons and tons of encoding
|> speed. Something has to feed all that VoIP, satellite set top stuff,
|> download-on-demand, multimedia chat. OK, it is a niche, but a comfortably
|> large and commercially viable niche.

It's a bit of an unstable one, though. Quite a lot of it is because
the organisations involved find it easier to buy their way out of
their protocol shambles with processing power than to sort the chaos
out. The requirement would remain, even if properly engineered, but
the market would be a fraction of its current size. A sudden drop of
even a factor of 1.5 in demand has quite major consequences ....

It may be a lot of protocols, but there are good reasons for each of
them, and these reasons are not going away. The industries behind them
are three times as big as the entire IT industry; almost as big as
cosmetics.

I quite agree that such commercial/political/social problems tend to
be very long-lived, but occasionally a new approach takes off and the
old ones get sidelined incredibly rapidly. That will happen sometime,
but God alone knows whether in a year or so, a decade or so, or not
for even longer.

Just as with the missing multicast implementations on the Internet,
I don't think this will materialise. There are too many centrifugal
forces involved, and there are sound technical reasons to employ
different codecs on fundamentally different networks.

Old G.711 (alaw/ulaw), and to a lesser extent G.726 (dect) is firmly
entrenched in the ISDN world.. They tried to upgrade to what was then
called G.722 (a G.726 style ADPCM protocol for wideband & stereo audio)
but it flopped. (the G.722 label has since been reassigned).

G.729 is the winner for all the hardware devices on the Internet. It
is a stellar codec for the normal conditions on the Internet, with
low packet loss, but sometimes high jitter, and a need for good PLC
for the bursty errors. It sounds very good. It is normally done in
hardware at the end user device; but good software implementations exists.
It can be extended with a higher frequency and dynamic range, but the
resulting stream is still readable by a "dumb" G.729 client. It saves
on bandwidth, which is still needed on the Internet, especially for
uplinks and mobile applications.

GSM and followons (GSM-HR; GSM-EFR, AMR) is fully entrenched in the
mobile world. They work well with the cell-oriented nature of that
network, and the high packet loss; regularly in the 20-30% range.

Sounds iffy at times, but people have gotten used to it. GSM-EFR
and AMR are better. AMR is really a wrapper around 8 different
codecs (really 3 codecs, with several more parameter sets).

I don't expect GSM to go away anytime soon.

The general answer is that we need a paradigm shift, even in HPC,
which is perhaps the longest-established parallel application area.
Most of the applications and almost all of the standards and tools
assume a relatively small number of very powerful processors. There
are alternative approaches, but they are not currently active, as I
have mentioned before.

All the multimedia stuff requires lots of processing power, but
it parallises pretty well; at least as long as the processors are
in the 500+ mips range.

We try to keep codec translations to a minimum, but with the three-way
fragmentation we see (VoIP/G.729, ISDN/DECT:G.711/G.726, and GSM etc with
GSM 06.10/AMR) we must expect telephone calls to need transcoding
in at least 90% of cases. The upside is that we can dispense with a
lot of the echo cancellers and other signal processing used in POTS when
the networks are fully digital, one way or another. The echo cancelling,
PLC, dejittering etc etc can also be pushed to the network edge.

I would expect core processing to go up by orders of magnitude. A major
winner will be a large-scale deployment of direct GSM-G.729 transcoding
while staying inside the vocoder (and not expanding to law/linear); and
keeping the larger frequency band and dynamic range across the encoding.

If this is a GSM-EFR to G.729ef transcoding we will keep a dynamic
range of 22 dB and a frequency response of 150-12000 Hz, while a detour
to alaw will limit us to 15 dB and 330-3700 Hz. This is the way the
world is moving. All the CPE chipsets handle wide frequency response now.

The downside is that the intelligence needed in the core processing
goes up, even if the total bit twiddling needs go down. We must expect
to handle software signal processing in the network cores for all
the foreseeable future.

-- mrr

.

Relevant Pages

  • Compiler positions available for week ending July 30
    ... uptimes of production applications you've written been measured in ... Current Linux and UNIX systems programming experience is highly ... High-availability Linux & UNIX network application programming ... Subject: Compiler Jobs in Bangalore ...
    (comp.compilers)
  • Re: Stoppong Kazaa With Trustix
    ... STOP FILE-SHARING APPLICATIONS ON YOUR NETWORK ... inbound/outbound packets at the network level. ... match protocol fasttrack ...
    (comp.security.firewalls)
  • Re: TCP Window Size
    ... I also like all those fights between network ... guys and applications guys. ... that your application has 90k to work within per session. ... terminal server queries across your multiple pipes, ...
    (comp.dcom.sys.cisco)
  • Audio CODECs
    ... Push content into coder, pass over network, extract content ... From some observations of existing CODECS: ... All try to apply different compression strategies which are ...
    (comp.dsp)
  • Re: Remote Desktop Faster/Easier than VPC
    ... I use RDC to connect to my office PC, but for my home network I'm using ... > recently with Axure RP, which I use to prototype Web applications), I ... > The only disadvantage is that you can't run your Windows applications ... > house stereo system with the WinXP machine as the server. ...
    (microsoft.public.mac.virtualpc)