Re: Question about Perl5 extended UTF-8 design

From: Philippe Verdy <verdy_p_at_wanadoo.fr>
Date: Fri, 6 Nov 2015 02:00:54 +0100

2015-11-05 23:11 GMT+01:00 Ilya Zakharevich <nospam-abuse_at_ilyaz.org> wrote
>
> • 128-bit architectures may be at hand (sooner or later).

This is specialation for something that is still not envisioned: a global
worldwide working space where users and applications would interoperate
transparently in a giant virtualized environment. However, this virtualized
environment will be supported by 64-bit OSes that will never need native
support of more the 64-bit pointers. Those 128-bit entities needed for
adressing will not be used to work on units of data but to address some
small selection of remote entities.

Softwares that would requiring parsing coompletely chunks of memory data
larger than 64-bit would be extremely inefficient, instead this data will
be internally structured/paged, and only virtually mapped to some 128 bit
global reference (such as GUID/UUIDs) only to select smaller chunks within
the structure (and in most cases those chunks will remain in a 32-bit space
(even in today's 64-bit OSes, the largest pages are 20-bit wide, but
typically 10-bit wide (512-byte sectors) to 12-bit wide (standard VMM and
I/O page sizes, networking MTUs), or about 16-bit wide (such as
transmission window for TCP). This will not eveolve significantly before a
major evolution in the worldwide Internet backbones requiring more than
about 1Gigabit/s (a speed not even needed for 4K HD video, but needed only
in massive computing grids, still built with a complex mesh of much slower
data links).

With 64-bit we already reach the physical limits of networking links, and
higher speeds using large buses are only for extremely local links whose
lengths are largely below a few millimters within chips themselves.

128 bit however is possible not for the working spaces (or document sizes)
it will be very unlikely that ANSI C/C++ "size_t" type will be more than
64-bit (ecept for a few experimentations which will fail to be more
efficient).

What is more realist is that internal buses and caches will be 128 bits or
even larger (this is already true for GPU memory), only to support more
parallelism or massive parallelism (and typically by using vectored
instructions working on sets of smaller values).

And some data need 128-bit values for their numerical ranges (ALUs in
CPU/GPU/APU are already 128-bit, as well as common floating point types)
where extra precision is necessary.

I doubt we'll ever see any true native 128-bit architecture in any time of
our remaining life. We are still very far from the limit of the 64-bit
architecture and it won't happend before the next century (if the current
sequential binary model for computing is still used at that time, may be
computing will use predictive technologies returning only heuristic results
with a very high probability of giving a good solution to the problems
we'll need to solve extremely rapidly, and those solutions will then be
validated using today's binary logic with 64-bit computing).

Even in the case where a global 128-bit networking space would appear,
users will never be exposed to all that, msot of this content will be
unacessible to them (restricted by secuiry concerns or privacy) and simply
unmanageable by them : no one on earth is able to have any idea of what
2^64 bits of global data represents, no one will ever need it in their
whole life. That amount of data will only be partly implemented by large
organisations trying to build a giant cloud and whiching to interoperate by
coordinating their addressing spaces (for that we have now IPv6).

So your "sooner or later" is very optimistic.

IMHO we'll stay with 64-bit architectures for very long, up to the time
where our seuqnetial computing model will be deprecated and the concept of
native integer sizes will be obsoleted and replaced by other kinds of
computing "units" (notably parallel vectors, distributed computing, and
heuristic computing, or may be optical computing based on Fourier
transforms on analog signals or quantum computing, where our simple notion
of "integers" or even "bits" will not even be placeable into individual
physically placed units; their persistence will not even be localized, and
there will be redundant/fault-tolerant placements).

In fact our computing limits wil no longer be in terms of storage space,
but in terms of access time, distance and predictability of results.

The next technologies for faster computing will be certainly
predictive/probabilistic rather than affirmative (with today's Turing/Von
Neumann machines). "Algorithms" for working with it will be completely
different. Fuzzy logic will be everywhere and we'll even need less the
binary logic except for small problems. We'll have to live with the
possibility of errors but anyway we already have to live with them evne
with our binary logic (due to human bugs, haardware faults, accidents, and
so on...) In most problems we don't even need to have 100% proven solutions

(e.g. viewing a high-quality video, we already accept the possibility of
some "quirks" occuring, and we already accept some minor alterationj of the
exact pixel colors in which we can't even note any visible difference from
the original ; another example is in what we call a "scientific proof"
which is in fact only a solution with the highest probability of being
correct in almost all known contexts, because we can never reproduce
exactly the same exprimental environment: even a basic binary NAND gate
cannot be warrantied at 100% of always returning a "0" state after a
defined delay when its inputs are all "1"). We can certainly produce
results with the same (or better) probability of giving the expected result
using fuzzy logic (or quantum logic) rather then existing binary logic, and
certainly with smaller computing delays (and better throughputs and better
fault torlerance, incliuding after hardware faults or damages, and even
with better security).
Received on Thu Nov 05 2015 - 19:02:11 CST

This archive was generated by hypermail 2.2.0 : Thu Nov 05 2015 - 19:02:11 CST