On 12/05/18 22:42, Phil Hobbs wrote:
On 05/12/18 17:08, gnuarm.deletethisbit@gmail.com wrote:
On Saturday, May 12, 2018 at 2:57:21 PM UTC-4, Phil Hobbs wrote:
On 05/12/18 14:38, Tom Gardner wrote:
On 12/05/18 18:51, gnuarm.deletethisbit@gmail.com wrote:
On Saturday, May 12, 2018 at 12:16:56 PM UTC-4, Tom Gardner wrote:
On 12/05/18 16:53, gnuarm.deletethisbit@gmail.com wrote:
On Saturday, May 12, 2018 at 11:23:22 AM UTC-4, Tom Gardner wrote:
On 12/05/18 15:43, upsidedown@downunder.com wrote:
On Sat, 12 May 2018 06:42:19 -0700 (PDT),
gnuarm.deletethisbit@gmail.com wrote:
On Sunday, August 27, 2017 at 5:43:56 PM UTC-4, bitrex wrote:
On 08/27/2017 03:40 PM, Tim Williams wrote:
Not so bad when you've got so many to spare: example, dedicate
a few rows of cores as data routing (which can be any
combination you like: duplexed, synchronous, packetized,
variable length, addressed...), and use the remaining
perimeter
as your parallel processor. You might still get dozens of
cores in parallel that way, even if the utilization is
effectively maybe 20%.
Each core can "know" what the load is for the cores on its
perimeter; if some core needs to send a message to the
perimeter
a best-first/greedy-search algorithm like beam search might be
able to be used to find the path where passing would cause the
least disruption.
https://en.wikipedia.org/wiki/Beam_search
I know this is an old thread, but I came across it when looking
for something else and had a few brain cells wakened.
Not directly related to this issues, but some recollections of
articles in electronic journals from the early 1970's.
In one article it was speculated that one day in the far future
the processor clock speed would be over 1 GHz and calculating
sin/cos
etc. would be hyper fast. Apparently the editor assumed that
those
functions were calculated using Taylor series. The article
suggested
using the trigonometric equation
sin(a+b) = sin(a)cos(b) + cos(a)sin(b)
and doing sin(a) and cos(a) with table lookup.
The CORDIC algorithm was invented in 1956.
Two decades later implementing floating point plus CORDIC on a
6800
was
my first paid job as a vacation student. I still have the code
CORDIC was also easily implementable in hardware.
With sufficient small steps cos(b)=1 and sin(b) = b/2pi. In
reality,
the trigonometrical functions in those days were calculated
using 3rd
or 4th order polynomials for single precession, so not much
advantage.
On the Sinclair Scientific calculator, maybe.
In an other article an Intel representative was interviewed what
happens, when it is possible to integrate a million
transistors on a
single chip. He could not give a clear answer.
My guess is that the situation today is similar with 1000 or a
million processor cores available.
As always, the hardware is easy, but programming techniques for
multiprocessor systems are still in their infancy.
The *only* processors that have a decent hardware+software
story are
the XMOS xCORE processors with xC. They have been around in
several
generations for over a decade, and are *very* usable for *hard*
realtime applications.
The xC+xCORE has a good pedigree: the key concepts have been
around
since the 70s (xC/CSP) and 80s (xCORE/Treansputer).
Oh, yeah, you are *that* guy. Yes, we've had this discussion
before.
They are good for a small class of applications which they are
optimized
for. Otherwise the advantages of other processors or even FPGAs
make
them
more suitable.
Obviously.
But I haven't seen *any* application of the GA144 you mentioned. As
for the
1000 processors chips, I have seen zero implementations, zero
programming
techniques and zero applications for them. The XMOS devices are
therefore
(currently) infinitely superior.
Yes, the GA144 was designed as an experiment rather than with any
application
in mind. However, I'm told they have customers, one application in
particular was for an advanced hearing aid using something much more
advanced
than a graphic equalizer type of filter. Seems the original
prototype
required the use of a pair of TMS320C6xxx devices which use around
a watt
each if I remember correctly. This type of signal processing app has
potential for a multiprocessor with little memory, as long as it
doesn't get
too complex or if it needs external memory the bandwidth isn't too
high.
Of those, the programming techniques are the most difficult; get
those
right and implementations and applications may *follow*.
I strongly suspect that anything with 1000s of processors will
have no
significant advantages over an FPGA.
I don't see that. The super computers of today use standard
processors, not
FPGAs. "Tianhee-2 uses over 3 million Intel Xeon E5-2692v2 12C
cores",
although that is yesterday's fastest computer surpassed by "The
Sunway
TaihuLight uses a total of 40,960 Chinese-designed SW26010 manycore
64-bit
RISC processors based on the Sunway architecture.[6] Each
processor chip
contains 256 processing cores, and an additional four auxiliary
cores for
system management (also RISC cores, just more fully featured) for a
total of
10,649,600 CPU cores across the entire system."Â This monster uses 15
MW...
yes, 15 MW! A professor in college used to kid about throwing the
power
switch on his CPUMOB machine and watching the lights dim in
College Park.
The Sunway would do it for sure!
A new machine is due out any time now running at 130 PFLOPS. Called
the AI
Bridging Cloud Infrastructure, "The system will consist of 1,088
Primergy
CX2570 M4 servers, mounted in Fujitsu's Primergy CX400 M4 multi-node
servers,
with each server featuring components such as two Intel Xeon Gold
processor
CPUs, four NVIDIA Tesla V100 GPU computing cards, and Intel SSD DC
P4600
storage."Â Expected power consumption will be down to only 3 MW.
I was assuming comparing FPGAs with something /vaguely/
similar to the GA144, or that Sony cell processor, or
that intel experiment with 80 cores on a chip.
Comparing something that, as I intended, fitted on a large
PCB and plus into the mains with something that fits on a
tennis court and plugs into a substation isn't really very
enlightening.
There's a fundamental problem with parallel computing
without shared memory[1]: choosing the granularity of
parallelism. Too small and the comms costs dominate,
too large and you have to copy too much context and
wait a long time for other computations to complete.
That has been an unsolved problem since the 1960s,
except for applications that are known as "embarrassingly
parallel". Canonical examples of embarrassingly parallel
computations are monte carlo simulations, telecom/financial
systems, some place/route algorithms, some simulated
annealing algorithms.
Cache coherence traffic grows faster than the number of cores, and
eventually dominates unless you go to a NUMA architecture.
Not if you don't use cache.
Rick C.
It's got nothing to do with you, it's the processor architecture. If
you want global cache coherence in a highly multicore processor, it
has to be architected to support that. If you do your own custom CPU
in FPGA, you can do whatever you want, but general purpose means
general purpose.
Caches are a red herring. If you get rid of them
(hello xCORE!) then you still have global memory
coherence to screw you up.
IMNSHO you /don't/ want global memory coherence in
a highly multicore system, because the penalties
for achieving that are unacceptable.
Ditto global clocks.
Ditto global time.
(Read Leslie Lamport for the latter!)
On 12/05/18 22:40, Phil Hobbs wrote:
On 05/12/18 16:15, Tom Gardner wrote:
On 12/05/18 19:57, Phil Hobbs wrote:
On 05/12/18 14:38, Tom Gardner wrote:
On 12/05/18 18:51, gnuarm.deletethisbit@gmail.com wrote:
On Saturday, May 12, 2018 at 12:16:56 PM UTC-4, Tom Gardner wrote:
On 12/05/18 16:53, gnuarm.deletethisbit@gmail.com wrote:
On Saturday, May 12, 2018 at 11:23:22 AM UTC-4, Tom Gardner wrote:
On 12/05/18 15:43, upsidedown@downunder.com wrote:
On Sat, 12 May 2018 06:42:19 -0700 (PDT),
gnuarm.deletethisbit@gmail.com wrote:
On Sunday, August 27, 2017 at 5:43:56 PM UTC-4, bitrex wrote:
On 08/27/2017 03:40 PM, Tim Williams wrote:
Not so bad when you've got so many to spare: example, dedicate
a few rows of cores as data routing (which can be any
combination you like: duplexed, synchronous, packetized,
variable length, addressed...), and use the remaining
perimeter
as your parallel processor. You might still get dozens of
cores in parallel that way, even if the utilization is
effectively maybe 20%.
Each core can "know" what the load is for the cores on its
perimeter; if some core needs to send a message to the
perimeter
a best-first/greedy-search algorithm like beam search might be
able to be used to find the path where passing would cause the
least disruption.
https://en.wikipedia.org/wiki/Beam_search
I know this is an old thread, but I came across it when looking
for something else and had a few brain cells wakened.
Not directly related to this issues, but some recollections of
articles in electronic journals from the early 1970's.
In one article it was speculated that one day in the far
future the processor clock speed would be over 1 GHz and
calculating sin/cos
etc. would be hyper fast. Apparently the editor assumed that
those
functions were calculated using Taylor series. The article
suggested
using the trigonometric equation
sin(a+b) = sin(a)cos(b) + cos(a)sin(b)
and doing sin(a) and cos(a) with table lookup.
The CORDIC algorithm was invented in 1956.
Two decades later implementing floating point plus CORDIC on a
6800 was
my first paid job as a vacation student. I still have the code
CORDIC was also easily implementable in hardware.
With sufficient small steps cos(b)=1 and sin(b) = b/2pi. In
reality,
the trigonometrical functions in those days were calculated
using 3rd
or 4th order polynomials for single precession, so not much
advantage.
On the Sinclair Scientific calculator, maybe.
In an other article an Intel representative was interviewed what
happens, when it is possible to integrate a million
transistors on a
single chip. He could not give a clear answer.
My guess is that the situation today is similar with 1000 or a
million processor cores available.
As always, the hardware is easy, but programming techniques for
multiprocessor systems are still in their infancy.
The *only* processors that have a decent hardware+software
story are
the XMOS xCORE processors with xC. They have been around in
several
generations for over a decade, and are *very* usable for *hard*
realtime applications.
The xC+xCORE has a good pedigree: the key concepts have been
around
since the 70s (xC/CSP) and 80s (xCORE/Treansputer).
Oh, yeah, you are *that* guy. Yes, we've had this discussion
before.
They are good for a small class of applications which they are
optimized
for. Otherwise the advantages of other processors or even FPGAs
make them
more suitable.
Obviously.
But I haven't seen *any* application of the GA144 you mentioned.
As for the
1000 processors chips, I have seen zero implementations, zero
programming
techniques and zero applications for them. The XMOS devices are
therefore
(currently) infinitely superior.
Yes, the GA144 was designed as an experiment rather than with any
application
in mind. However, I'm told they have customers, one application in
particular was for an advanced hearing aid using something much
more advanced
than a graphic equalizer type of filter. Seems the original
prototype
required the use of a pair of TMS320C6xxx devices which use around
a watt
each if I remember correctly. This type of signal processing app has
potential for a multiprocessor with little memory, as long as it
doesn't get
too complex or if it needs external memory the bandwidth isn't too
high.
Of those, the programming techniques are the most difficult; get
those
right and implementations and applications may *follow*.
I strongly suspect that anything with 1000s of processors will
have no
significant advantages over an FPGA.
I don't see that. The super computers of today use standard
processors, not
FPGAs. "Tianhee-2 uses over 3 million Intel Xeon E5-2692v2 12C
cores",
although that is yesterday's fastest computer surpassed by "The
Sunway
TaihuLight uses a total of 40,960 Chinese-designed SW26010
manycore 64-bit
RISC processors based on the Sunway architecture.[6] Each
processor chip
contains 256 processing cores, and an additional four auxiliary
cores for
system management (also RISC cores, just more fully featured) for
a total of
10,649,600 CPU cores across the entire system."Â This monster uses
15 MW...
yes, 15 MW! A professor in college used to kid about throwing the
power
switch on his CPUMOB machine and watching the lights dim in
College Park.
The Sunway would do it for sure!
A new machine is due out any time now running at 130 PFLOPS.
Called the AI
Bridging Cloud Infrastructure, "The system will consist of 1,088
Primergy
CX2570 M4 servers, mounted in Fujitsu's Primergy CX400 M4
multi-node servers,
with each server featuring components such as two Intel Xeon Gold
processor
CPUs, four NVIDIA Tesla V100 GPU computing cards, and Intel SSD DC
P4600
storage."Â Expected power consumption will be down to only 3 MW.
I was assuming comparing FPGAs with something /vaguely/
similar to the GA144, or that Sony cell processor, or
that intel experiment with 80 cores on a chip.
Comparing something that, as I intended, fitted on a large
PCB and plus into the mains with something that fits on a
tennis court and plugs into a substation isn't really very
enlightening.
There's a fundamental problem with parallel computing
without shared memory[1]: choosing the granularity of
parallelism. Too small and the comms costs dominate,
too large and you have to copy too much context and
wait a long time for other computations to complete.
That has been an unsolved problem since the 1960s,
except for applications that are known as "embarrassingly
parallel". Canonical examples of embarrassingly parallel
computations are monte carlo simulations, telecom/financial
systems, some place/route algorithms, some simulated
annealing algorithms.
Cache coherence traffic grows faster than the number of cores, and
eventually dominates unless you go to a NUMA architecture.
Oh, indeed, that is inherently non-scalable, with
/any/ memory architecture. Sure people have pushed
the limit back a bit, but not cleanly.
The fundamental problem is that low-level softies would
like to think that they are still programming PDP11s in
K&R C. They aren't, and there are an appalling number
of poorly understood band-aids in modern C that attempt
to preserve that illusion. (And may preserve it if you
get all the incantations for your compiler+version
exactly right)
The sooner the flat-memory-space single-instruction-
at-a-time mirage is superseded, the better. Currently
the best option, according to the HPC mob that
traditionally push all computational boundaries, is
message-passing. But that is poorly supported by C.
For an amusing speed-read, have a look at
"C Is Not a Low-level Language. Your computer
is not a fast PDP-11."
https://queue.acm.org/detail.cfm?id=3212479
It has examples of where people in the trenches
don't understand what's going on. For example:
  "A 2015 survey of C programmers, compiler writers,
  and standards committee members raised several
  issues about the comprehensibility of C. For
  example, C permits an implementation to insert
  padding into structures (but not into arrays)
  to ensure that all fields have a useful alignment
  for the target. If you zero a structure and then
  set some of the fields, will the padding bits
  all be zero? According to the results of the
  survey, 36 percent were sure that they would
  be, and 29 percent didn't know. Depending on
  the compiler (and optimization level), it may
  or may not be.
Fun. He's a CS academic, so he probably doesn't write programs and so
doesn't realize how much stuff can't reasonably be done in his
favourite toy language, but it's a good read anyhow.
Two choices: either the toy language is C,
or it can't be reasonably be done in C
On 05/12/18 17:08, gnuarm.deletethisbit@gmail.com wrote:
On Saturday, May 12, 2018 at 2:57:21 PM UTC-4, Phil Hobbs wrote:
On 05/12/18 14:38, Tom Gardner wrote:
On 12/05/18 18:51, gnuarm.deletethisbit@gmail.com wrote:
On Saturday, May 12, 2018 at 12:16:56 PM UTC-4, Tom Gardner wrote:
On 12/05/18 16:53, gnuarm.deletethisbit@gmail.com wrote:
On Saturday, May 12, 2018 at 11:23:22 AM UTC-4, Tom Gardner wrote:
On 12/05/18 15:43, upsidedown@downunder.com wrote:
On Sat, 12 May 2018 06:42:19 -0700 (PDT),
gnuarm.deletethisbit@gmail.com wrote:
On Sunday, August 27, 2017 at 5:43:56 PM UTC-4, bitrex wrote:
On 08/27/2017 03:40 PM, Tim Williams wrote:
Not so bad when you've got so many to spare: example, dedicate
a few rows of cores as data routing (which can be any
combination you like: duplexed, synchronous, packetized,
variable length, addressed...), and use the remaining perimeter
as your parallel processor. You might still get dozens of
cores in parallel that way, even if the utilization is
effectively maybe 20%.
Each core can "know" what the load is for the cores on its
perimeter; if some core needs to send a message to the perimeter
a best-first/greedy-search algorithm like beam search might be
able to be used to find the path where passing would cause the
least disruption.
https://en.wikipedia.org/wiki/Beam_search
I know this is an old thread, but I came across it when looking
for something else and had a few brain cells wakened.
Not directly related to this issues, but some recollections of
articles in electronic journals from the early 1970's.
In one article it was speculated that one day in the far future
the processor clock speed would be over 1 GHz and calculating sin/cos
etc. would be hyper fast. Apparently the editor assumed that those
functions were calculated using Taylor series. The article suggested
using the trigonometric equation
sin(a+b) = sin(a)cos(b) + cos(a)sin(b)
and doing sin(a) and cos(a) with table lookup.
The CORDIC algorithm was invented in 1956.
Two decades later implementing floating point plus CORDIC on a 6800
was
my first paid job as a vacation student. I still have the code
CORDIC was also easily implementable in hardware.
With sufficient small steps cos(b)=1 and sin(b) = b/2pi. In reality,
the trigonometrical functions in those days were calculated using 3rd
or 4th order polynomials for single precession, so not much
advantage.
On the Sinclair Scientific calculator, maybe.
In an other article an Intel representative was interviewed what
happens, when it is possible to integrate a million transistors on a
single chip. He could not give a clear answer.
My guess is that the situation today is similar with 1000 or a
million processor cores available.
As always, the hardware is easy, but programming techniques for
multiprocessor systems are still in their infancy.
The *only* processors that have a decent hardware+software story are
the XMOS xCORE processors with xC. They have been around in several
generations for over a decade, and are *very* usable for *hard*
realtime applications.
The xC+xCORE has a good pedigree: the key concepts have been around
since the 70s (xC/CSP) and 80s (xCORE/Treansputer).
Oh, yeah, you are *that* guy. Yes, we've had this discussion before.
They are good for a small class of applications which they are
optimized
for. Otherwise the advantages of other processors or even FPGAs make
them
more suitable.
Obviously.
But I haven't seen *any* application of the GA144 you mentioned. As
for the
1000 processors chips, I have seen zero implementations, zero
programming
techniques and zero applications for them. The XMOS devices are
therefore
(currently) infinitely superior.
Yes, the GA144 was designed as an experiment rather than with any
application
in mind. However, I'm told they have customers, one application in
particular was for an advanced hearing aid using something much more
advanced
than a graphic equalizer type of filter. Seems the original prototype
required the use of a pair of TMS320C6xxx devices which use around a watt
each if I remember correctly. This type of signal processing app has
potential for a multiprocessor with little memory, as long as it
doesn't get
too complex or if it needs external memory the bandwidth isn't too high.
Of those, the programming techniques are the most difficult; get those
right and implementations and applications may *follow*.
I strongly suspect that anything with 1000s of processors will have no
significant advantages over an FPGA.
I don't see that. The super computers of today use standard
processors, not
FPGAs. "Tianhee-2 uses over 3 million Intel Xeon E5-2692v2 12C cores",
although that is yesterday's fastest computer surpassed by "The Sunway
TaihuLight uses a total of 40,960 Chinese-designed SW26010 manycore
64-bit
RISC processors based on the Sunway architecture.[6] Each processor chip
contains 256 processing cores, and an additional four auxiliary cores for
system management (also RISC cores, just more fully featured) for a
total of
10,649,600 CPU cores across the entire system."Â This monster uses 15
MW...
yes, 15 MW! A professor in college used to kid about throwing the power
switch on his CPUMOB machine and watching the lights dim in College Park.
The Sunway would do it for sure!
A new machine is due out any time now running at 130 PFLOPS. Called
the AI
Bridging Cloud Infrastructure, "The system will consist of 1,088 Primergy
CX2570 M4 servers, mounted in Fujitsu's Primergy CX400 M4 multi-node
servers,
with each server featuring components such as two Intel Xeon Gold
processor
CPUs, four NVIDIA Tesla V100 GPU computing cards, and Intel SSD DC P4600
storage."Â Expected power consumption will be down to only 3 MW.
I was assuming comparing FPGAs with something /vaguely/
similar to the GA144, or that Sony cell processor, or
that intel experiment with 80 cores on a chip.
Comparing something that, as I intended, fitted on a large
PCB and plus into the mains with something that fits on a
tennis court and plugs into a substation isn't really very
enlightening.
There's a fundamental problem with parallel computing
without shared memory[1]: choosing the granularity of
parallelism. Too small and the comms costs dominate,
too large and you have to copy too much context and
wait a long time for other computations to complete.
That has been an unsolved problem since the 1960s,
except for applications that are known as "embarrassingly
parallel". Canonical examples of embarrassingly parallel
computations are monte carlo simulations, telecom/financial
systems, some place/route algorithms, some simulated
annealing algorithms.
Cache coherence traffic grows faster than the number of cores, and
eventually dominates unless you go to a NUMA architecture.
Not if you don't use cache.
Rick C.
It's got nothing to do with you, it's the processor architecture. If you want
global cache coherence in a highly multicore processor, it has to be architected
to support that. If you do your own custom CPU in FPGA, you can do whatever you
want, but general purpose means general purpose.
On 05/12/18 16:15, Tom Gardner wrote:
On 12/05/18 19:57, Phil Hobbs wrote:
On 05/12/18 14:38, Tom Gardner wrote:
On 12/05/18 18:51, gnuarm.deletethisbit@gmail.com wrote:
On Saturday, May 12, 2018 at 12:16:56 PM UTC-4, Tom Gardner wrote:
On 12/05/18 16:53, gnuarm.deletethisbit@gmail.com wrote:
On Saturday, May 12, 2018 at 11:23:22 AM UTC-4, Tom Gardner wrote:
On 12/05/18 15:43, upsidedown@downunder.com wrote:
On Sat, 12 May 2018 06:42:19 -0700 (PDT),
gnuarm.deletethisbit@gmail.com wrote:
On Sunday, August 27, 2017 at 5:43:56 PM UTC-4, bitrex wrote:
On 08/27/2017 03:40 PM, Tim Williams wrote:
Not so bad when you've got so many to spare: example, dedicate
a few rows of cores as data routing (which can be any
combination you like: duplexed, synchronous, packetized,
variable length, addressed...), and use the remaining perimeter
as your parallel processor. You might still get dozens of
cores in parallel that way, even if the utilization is
effectively maybe 20%.
Each core can "know" what the load is for the cores on its
perimeter; if some core needs to send a message to the perimeter
a best-first/greedy-search algorithm like beam search might be
able to be used to find the path where passing would cause the
least disruption.
https://en.wikipedia.org/wiki/Beam_search
I know this is an old thread, but I came across it when looking
for something else and had a few brain cells wakened.
Not directly related to this issues, but some recollections of
articles in electronic journals from the early 1970's.
In one article it was speculated that one day in the far future the
processor clock speed would be over 1 GHz and calculating sin/cos
etc. would be hyper fast. Apparently the editor assumed that those
functions were calculated using Taylor series. The article suggested
using the trigonometric equation
sin(a+b) = sin(a)cos(b) + cos(a)sin(b)
and doing sin(a) and cos(a) with table lookup.
The CORDIC algorithm was invented in 1956.
Two decades later implementing floating point plus CORDIC on a 6800 was
my first paid job as a vacation student. I still have the code
CORDIC was also easily implementable in hardware.
With sufficient small steps cos(b)=1 and sin(b) = b/2pi. In reality,
the trigonometrical functions in those days were calculated using 3rd
or 4th order polynomials for single precession, so not much
advantage.
On the Sinclair Scientific calculator, maybe.
In an other article an Intel representative was interviewed what
happens, when it is possible to integrate a million transistors on a
single chip. He could not give a clear answer.
My guess is that the situation today is similar with 1000 or a
million processor cores available.
As always, the hardware is easy, but programming techniques for
multiprocessor systems are still in their infancy.
The *only* processors that have a decent hardware+software story are
the XMOS xCORE processors with xC. They have been around in several
generations for over a decade, and are *very* usable for *hard*
realtime applications.
The xC+xCORE has a good pedigree: the key concepts have been around
since the 70s (xC/CSP) and 80s (xCORE/Treansputer).
Oh, yeah, you are *that* guy. Yes, we've had this discussion before.
They are good for a small class of applications which they are optimized
for. Otherwise the advantages of other processors or even FPGAs make them
more suitable.
Obviously.
But I haven't seen *any* application of the GA144 you mentioned. As for the
1000 processors chips, I have seen zero implementations, zero programming
techniques and zero applications for them. The XMOS devices are therefore
(currently) infinitely superior.
Yes, the GA144 was designed as an experiment rather than with any application
in mind. However, I'm told they have customers, one application in
particular was for an advanced hearing aid using something much more advanced
than a graphic equalizer type of filter. Seems the original prototype
required the use of a pair of TMS320C6xxx devices which use around a watt
each if I remember correctly. This type of signal processing app has
potential for a multiprocessor with little memory, as long as it doesn't get
too complex or if it needs external memory the bandwidth isn't too high.
Of those, the programming techniques are the most difficult; get those
right and implementations and applications may *follow*.
I strongly suspect that anything with 1000s of processors will have no
significant advantages over an FPGA.
I don't see that. The super computers of today use standard processors, not
FPGAs. "Tianhee-2 uses over 3 million Intel Xeon E5-2692v2 12C cores",
although that is yesterday's fastest computer surpassed by "The Sunway
TaihuLight uses a total of 40,960 Chinese-designed SW26010 manycore 64-bit
RISC processors based on the Sunway architecture.[6] Each processor chip
contains 256 processing cores, and an additional four auxiliary cores for
system management (also RISC cores, just more fully featured) for a total of
10,649,600 CPU cores across the entire system."Â This monster uses 15 MW...
yes, 15 MW! A professor in college used to kid about throwing the power
switch on his CPUMOB machine and watching the lights dim in College Park.
The Sunway would do it for sure!
A new machine is due out any time now running at 130 PFLOPS. Called the AI
Bridging Cloud Infrastructure, "The system will consist of 1,088 Primergy
CX2570 M4 servers, mounted in Fujitsu's Primergy CX400 M4 multi-node servers,
with each server featuring components such as two Intel Xeon Gold processor
CPUs, four NVIDIA Tesla V100 GPU computing cards, and Intel SSD DC P4600
storage."Â Expected power consumption will be down to only 3 MW.
I was assuming comparing FPGAs with something /vaguely/
similar to the GA144, or that Sony cell processor, or
that intel experiment with 80 cores on a chip.
Comparing something that, as I intended, fitted on a large
PCB and plus into the mains with something that fits on a
tennis court and plugs into a substation isn't really very
enlightening.
There's a fundamental problem with parallel computing
without shared memory[1]: choosing the granularity of
parallelism. Too small and the comms costs dominate,
too large and you have to copy too much context and
wait a long time for other computations to complete.
That has been an unsolved problem since the 1960s,
except for applications that are known as "embarrassingly
parallel". Canonical examples of embarrassingly parallel
computations are monte carlo simulations, telecom/financial
systems, some place/route algorithms, some simulated
annealing algorithms.
Cache coherence traffic grows faster than the number of cores, and eventually
dominates unless you go to a NUMA architecture.
Oh, indeed, that is inherently non-scalable, with
/any/ memory architecture. Sure people have pushed
the limit back a bit, but not cleanly.
The fundamental problem is that low-level softies would
like to think that they are still programming PDP11s in
K&R C. They aren't, and there are an appalling number
of poorly understood band-aids in modern C that attempt
to preserve that illusion. (And may preserve it if you
get all the incantations for your compiler+version
exactly right)
The sooner the flat-memory-space single-instruction-
at-a-time mirage is superseded, the better. Currently
the best option, according to the HPC mob that
traditionally push all computational boundaries, is
message-passing. But that is poorly supported by C.
For an amusing speed-read, have a look at
"C Is Not a Low-level Language. Your computer
is not a fast PDP-11."
https://queue.acm.org/detail.cfm?id=3212479
It has examples of where people in the trenches
don't understand what's going on. For example:
  "A 2015 survey of C programmers, compiler writers,
  and standards committee members raised several
  issues about the comprehensibility of C. For
  example, C permits an implementation to insert
  padding into structures (but not into arrays)
  to ensure that all fields have a useful alignment
  for the target. If you zero a structure and then
  set some of the fields, will the padding bits
  all be zero? According to the results of the
  survey, 36 percent were sure that they would
  be, and 29 percent didn't know. Depending on
  the compiler (and optimization level), it may
  or may not be.
Fun. He's a CS academic, so he probably doesn't write programs and so doesn't
realize how much stuff can't reasonably be done in his favourite toy language,
but it's a good read anyhow.
On 05/12/18 20:47, Tom Gardner wrote:
On 12/05/18 22:40, Phil Hobbs wrote:
On 05/12/18 16:15, Tom Gardner wrote:
On 12/05/18 19:57, Phil Hobbs wrote:
On 05/12/18 14:38, Tom Gardner wrote:
On 12/05/18 18:51, gnuarm.deletethisbit@gmail.com wrote:
On Saturday, May 12, 2018 at 12:16:56 PM UTC-4, Tom Gardner wrote:
On 12/05/18 16:53, gnuarm.deletethisbit@gmail.com wrote:
On Saturday, May 12, 2018 at 11:23:22 AM UTC-4, Tom Gardner wrote:
On 12/05/18 15:43, upsidedown@downunder.com wrote:
On Sat, 12 May 2018 06:42:19 -0700 (PDT),
gnuarm.deletethisbit@gmail.com wrote:
On Sunday, August 27, 2017 at 5:43:56 PM UTC-4, bitrex wrote:
On 08/27/2017 03:40 PM, Tim Williams wrote:
Not so bad when you've got so many to spare: example, dedicate
a few rows of cores as data routing (which can be any
combination you like: duplexed, synchronous, packetized,
variable length, addressed...), and use the remaining perimeter
as your parallel processor. You might still get dozens of
cores in parallel that way, even if the utilization is
effectively maybe 20%.
Each core can "know" what the load is for the cores on its
perimeter; if some core needs to send a message to the perimeter
a best-first/greedy-search algorithm like beam search might be
able to be used to find the path where passing would cause the
least disruption.
https://en.wikipedia.org/wiki/Beam_search
I know this is an old thread, but I came across it when looking
for something else and had a few brain cells wakened.
Not directly related to this issues, but some recollections of
articles in electronic journals from the early 1970's.
In one article it was speculated that one day in the far future the
processor clock speed would be over 1 GHz and calculating sin/cos
etc. would be hyper fast. Apparently the editor assumed that those
functions were calculated using Taylor series. The article suggested
using the trigonometric equation
sin(a+b) = sin(a)cos(b) + cos(a)sin(b)
and doing sin(a) and cos(a) with table lookup.
The CORDIC algorithm was invented in 1956.
Two decades later implementing floating point plus CORDIC on a 6800 was
my first paid job as a vacation student. I still have the code
CORDIC was also easily implementable in hardware.
With sufficient small steps cos(b)=1 and sin(b) = b/2pi. In reality,
the trigonometrical functions in those days were calculated using 3rd
or 4th order polynomials for single precession, so not much
advantage.
On the Sinclair Scientific calculator, maybe.
In an other article an Intel representative was interviewed what
happens, when it is possible to integrate a million transistors on a
single chip. He could not give a clear answer.
My guess is that the situation today is similar with 1000 or a
million processor cores available.
As always, the hardware is easy, but programming techniques for
multiprocessor systems are still in their infancy.
The *only* processors that have a decent hardware+software story are
the XMOS xCORE processors with xC. They have been around in several
generations for over a decade, and are *very* usable for *hard*
realtime applications.
The xC+xCORE has a good pedigree: the key concepts have been around
since the 70s (xC/CSP) and 80s (xCORE/Treansputer).
Oh, yeah, you are *that* guy. Yes, we've had this discussion before.
They are good for a small class of applications which they are optimized
for. Otherwise the advantages of other processors or even FPGAs make them
more suitable.
Obviously.
But I haven't seen *any* application of the GA144 you mentioned. As for the
1000 processors chips, I have seen zero implementations, zero programming
techniques and zero applications for them. The XMOS devices are therefore
(currently) infinitely superior.
Yes, the GA144 was designed as an experiment rather than with any
application
in mind. However, I'm told they have customers, one application in
particular was for an advanced hearing aid using something much more
advanced
than a graphic equalizer type of filter. Seems the original prototype
required the use of a pair of TMS320C6xxx devices which use around a watt
each if I remember correctly. This type of signal processing app has
potential for a multiprocessor with little memory, as long as it doesn't get
too complex or if it needs external memory the bandwidth isn't too high.
Of those, the programming techniques are the most difficult; get those
right and implementations and applications may *follow*.
I strongly suspect that anything with 1000s of processors will have no
significant advantages over an FPGA.
I don't see that. The super computers of today use standard processors, not
FPGAs. "Tianhee-2 uses over 3 million Intel Xeon E5-2692v2 12C cores",
although that is yesterday's fastest computer surpassed by "The Sunway
TaihuLight uses a total of 40,960 Chinese-designed SW26010 manycore 64-bit
RISC processors based on the Sunway architecture.[6] Each processor chip
contains 256 processing cores, and an additional four auxiliary cores for
system management (also RISC cores, just more fully featured) for a total of
10,649,600 CPU cores across the entire system."Â This monster uses 15 MW...
yes, 15 MW! A professor in college used to kid about throwing the power
switch on his CPUMOB machine and watching the lights dim in College Park.
The Sunway would do it for sure!
A new machine is due out any time now running at 130 PFLOPS. Called the AI
Bridging Cloud Infrastructure, "The system will consist of 1,088 Primergy
CX2570 M4 servers, mounted in Fujitsu's Primergy CX400 M4 multi-node
servers,
with each server featuring components such as two Intel Xeon Gold processor
CPUs, four NVIDIA Tesla V100 GPU computing cards, and Intel SSD DC P4600
storage."Â Expected power consumption will be down to only 3 MW.
I was assuming comparing FPGAs with something /vaguely/
similar to the GA144, or that Sony cell processor, or
that intel experiment with 80 cores on a chip.
Comparing something that, as I intended, fitted on a large
PCB and plus into the mains with something that fits on a
tennis court and plugs into a substation isn't really very
enlightening.
There's a fundamental problem with parallel computing
without shared memory[1]: choosing the granularity of
parallelism. Too small and the comms costs dominate,
too large and you have to copy too much context and
wait a long time for other computations to complete.
That has been an unsolved problem since the 1960s,
except for applications that are known as "embarrassingly
parallel". Canonical examples of embarrassingly parallel
computations are monte carlo simulations, telecom/financial
systems, some place/route algorithms, some simulated
annealing algorithms.
Cache coherence traffic grows faster than the number of cores, and
eventually dominates unless you go to a NUMA architecture.
Oh, indeed, that is inherently non-scalable, with
/any/ memory architecture. Sure people have pushed
the limit back a bit, but not cleanly.
The fundamental problem is that low-level softies would
like to think that they are still programming PDP11s in
K&R C. They aren't, and there are an appalling number
of poorly understood band-aids in modern C that attempt
to preserve that illusion. (And may preserve it if you
get all the incantations for your compiler+version
exactly right)
The sooner the flat-memory-space single-instruction-
at-a-time mirage is superseded, the better. Currently
the best option, according to the HPC mob that
traditionally push all computational boundaries, is
message-passing. But that is poorly supported by C.
For an amusing speed-read, have a look at
"C Is Not a Low-level Language. Your computer
is not a fast PDP-11."
https://queue.acm.org/detail.cfm?id=3212479
It has examples of where people in the trenches
don't understand what's going on. For example:
  "A 2015 survey of C programmers, compiler writers,
  and standards committee members raised several
  issues about the comprehensibility of C. For
  example, C permits an implementation to insert
  padding into structures (but not into arrays)
  to ensure that all fields have a useful alignment
  for the target. If you zero a structure and then
  set some of the fields, will the padding bits
  all be zero? According to the results of the
  survey, 36 percent were sure that they would
  be, and 29 percent didn't know. Depending on
  the compiler (and optimization level), it may
  or may not be.
Fun. He's a CS academic, so he probably doesn't write programs and so
doesn't realize how much stuff can't reasonably be done in his favourite toy
language, but it's a good read anyhow.
Two choices: either the toy language is C,
or it can't be reasonably be done in C
Your point being?Â
In his case, the toy language is Erlang.
But I've been using C for 35 years, and I imagine
I'll continue to use it.
Why on earth not? Just pissing off CS academics is reason enough, not to
mention that it gets the job done.
)On 05/12/18 20:51, Tom Gardner wrote:
On 12/05/18 22:42, Phil Hobbs wrote:
On 05/12/18 17:08, gnuarm.deletethisbit@gmail.com wrote:
On Saturday, May 12, 2018 at 2:57:21 PM UTC-4, Phil Hobbs wrote:
On 05/12/18 14:38, Tom Gardner wrote:
On 12/05/18 18:51, gnuarm.deletethisbit@gmail.com wrote:
On Saturday, May 12, 2018 at 12:16:56 PM UTC-4, Tom Gardner
wrote:
On 12/05/18 16:53, gnuarm.deletethisbit@gmail.com wrote:
On Saturday, May 12, 2018 at 11:23:22 AM UTC-4, Tom Gardner
wrote:
On 12/05/18 15:43, upsidedown@downunder.com wrote:
On Sat, 12 May 2018 06:42:19 -0700 (PDT),
gnuarm.deletethisbit@gmail.com wrote:
On Sunday, August 27, 2017 at 5:43:56 PM UTC-4, bitrex
wrote:
On 08/27/2017 03:40 PM, Tim Williams wrote:
Not so bad when you've got so many to spare:
example, dedicate a few rows of cores as data
routing (which can be any combination you like:
duplexed, synchronous, packetized, variable length,
addressed...), and use the remaining perimeter as
your parallel processor. You might still get
dozens of cores in parallel that way, even if the
utilization is effectively maybe 20%.
Each core can "know" what the load is for the cores
on its perimeter; if some core needs to send a
message to the perimeter a best-first/greedy-search
algorithm like beam search might be able to be used
to find the path where passing would cause the least
disruption.
https://en.wikipedia.org/wiki/Beam_search
I know this is an old thread, but I came across it when
looking for something else and had a few brain cells
wakened.
Not directly related to this issues, but some
recollections of articles in electronic journals from the
early 1970's.
In one article it was speculated that one day in the far
future the processor clock speed would be over 1 GHz and
calculating sin/cos etc. would be hyper fast. Apparently
the editor assumed that those functions were calculated
using Taylor series. The article suggested using the
trigonometric equation
sin(a+b) = sin(a)cos(b) + cos(a)sin(b)
and doing sin(a) and cos(a) with table lookup.
The CORDIC algorithm was invented in 1956.
Two decades later implementing floating point plus CORDIC
on a 6800 was my first paid job as a vacation student. I
still have the code
CORDIC was also easily implementable in hardware.
With sufficient small steps cos(b)=1 and sin(b) = b/2pi.
In reality, the trigonometrical functions in those days
were calculated using 3rd or 4th order polynomials for
single precession, so not much advantage.
On the Sinclair Scientific calculator, maybe.
In an other article an Intel representative was
interviewed what happens, when it is possible to
integrate a million transistors on a single chip. He
could not give a clear answer.
My guess is that the situation today is similar with 1000
or a million processor cores available.
As always, the hardware is easy, but programming techniques
for multiprocessor systems are still in their infancy.
The *only* processors that have a decent hardware+software
story are the XMOS xCORE processors with xC. They have been
around in several generations for over a decade, and are
*very* usable for *hard* realtime applications.
The xC+xCORE has a good pedigree: the key concepts have
been around since the 70s (xC/CSP) and 80s
(xCORE/Treansputer).
Oh, yeah, you are *that* guy. Yes, we've had this discussion
before. They are good for a small class of applications which
they are optimized for. Otherwise the advantages of other
processors or even FPGAs make them more suitable.
Obviously.
But I haven't seen *any* application of the GA144 you
mentioned. As for the 1000 processors chips, I have seen zero
implementations, zero programming techniques and zero
applications for them. The XMOS devices are therefore
(currently) infinitely superior.
Yes, the GA144 was designed as an experiment rather than with
any application in mind. However, I'm told they have customers,
one application in particular was for an advanced hearing aid
using something much more advanced than a graphic equalizer type
of filter. Seems the original prototype required the use of a
pair of TMS320C6xxx devices which use around a watt each if I
remember correctly. This type of signal processing app has
potential for a multiprocessor with little memory, as long as it
doesn't get too complex or if it needs external memory the
bandwidth isn't too high.
Of those, the programming techniques are the most difficult;
get those right and implementations and applications may
*follow*.
I strongly suspect that anything with 1000s of processors will
have no significant advantages over an FPGA.
I don't see that. The super computers of today use standard
processors, not FPGAs. "Tianhee-2 uses over 3 million Intel Xeon
E5-2692v2 12C cores", although that is yesterday's fastest
computer surpassed by "The Sunway TaihuLight uses a total of
40,960 Chinese-designed SW26010 manycore 64-bit RISC processors
based on the Sunway architecture.[6] Each processor chip contains
256 processing cores, and an additional four auxiliary cores for
system management (also RISC cores, just more fully featured) for
a total of 10,649,600 CPU cores across the entire system." This
monster uses 15 MW... yes, 15 MW! A professor in college used to
kid about throwing the power switch on his CPUMOB machine and
watching the lights dim in College Park. The Sunway would do it
for sure!
A new machine is due out any time now running at 130 PFLOPS.
Called the AI Bridging Cloud Infrastructure, "The system will
consist of 1,088 Primergy CX2570 M4 servers, mounted in Fujitsu's
Primergy CX400 M4 multi-node servers, with each server featuring
components such as two Intel Xeon Gold processor CPUs, four
NVIDIA Tesla V100 GPU computing cards, and Intel SSD DC P4600
storage." Expected power consumption will be down to only 3 MW.
I was assuming comparing FPGAs with something /vaguely/ similar to
the GA144, or that Sony cell processor, or that intel experiment
with 80 cores on a chip.
Comparing something that, as I intended, fitted on a large PCB and
plus into the mains with something that fits on a tennis court and
plugs into a substation isn't really very enlightening.
There's a fundamental problem with parallel computing without
shared memory[1]: choosing the granularity of parallelism. Too
small and the comms costs dominate, too large and you have to copy
too much context and wait a long time for other computations to
complete.
That has been an unsolved problem since the 1960s, except for
applications that are known as "embarrassingly parallel". Canonical
examples of embarrassingly parallel computations are monte carlo
simulations, telecom/financial systems, some place/route
algorithms, some simulated annealing algorithms.
Cache coherence traffic grows faster than the number of cores, and
eventually dominates unless you go to a NUMA architecture.
Not if you don't use cache.
Rick C.
It's got nothing to do with you, it's the processor architecture. If you
want global cache coherence in a highly multicore processor, it has to
be architected to support that. If you do your own custom CPU in FPGA,
you can do whatever you want, but general purpose means general purpose.
Caches are a red herring. If you get rid of them (hello xCORE!) then you
still have global memory coherence to screw you up.
IMNSHO you /don't/ want global memory coherence in a highly multicore
system, because the penalties for achieving that are unacceptable.
Ditto global clocks. Ditto global time.
(Read Leslie Lamport for the latter!)
SMPs are a lot more generally useful than less-symmetric systems. The more
you relax the coherence guarantees the more you restrict the range of
problems you can address efficiently.
On 12/05/18 15:43, upsidedown@downunder.com wrote:
On Sat, 12 May 2018 06:42:19 -0700 (PDT),
gnuarm.deletethisbit@gmail.com wrote:
On Sunday, August 27, 2017 at 5:43:56 PM UTC-4, bitrex wrote:
On 08/27/2017 03:40 PM, Tim Williams wrote:
Not so bad when you've got so many to spare: example, dedicate a few
rows of cores as data routing (which can be any combination you like:
duplexed, synchronous, packetized, variable length, addressed...), and
use the remaining perimeter as your parallel processor. You might still
get dozens of cores in parallel that way, even if the utilization is
effectively maybe 20%.
Each core can "know" what the load is for the cores on its perimeter; if
some core needs to send a message to the perimeter a
best-first/greedy-search algorithm like beam search might be able to be
used to find the path where passing would cause the least disruption.
https://en.wikipedia.org/wiki/Beam_search
I know this is an old thread, but I came across it when looking for something else and had a few brain cells wakened.
Not directly related to this issues, but some recollections of
articles in electronic journals from the early 1970's.
In one article it was speculated that one day in the far future the
processor clock speed would be over 1 GHz and calculating sin/cos etc.
would be hyper fast. Apparently the editor assumed that those
functions were calculated using Taylor series. The article suggested
using the trigonometric equation
sin(a+b) = sin(a)cos(b) + cos(a)sin(b)
and doing sin(a) and cos(a) with table lookup.
The CORDIC algorithm was invented in 1956.
Two decades later implementing floating point plus
CORDIC on a 6800 was my first paid job as a
vacation student. I still have the code
CORDIC was also easily implementable in hardware.
With sufficient small steps cos(b)=1 and sin(b) = b/2pi. In reality,
the trigonometrical functions in those days were calculated using 3rd
or 4th order polynomials for single precession, so not much advantage.
On the Sinclair Scientific calculator, maybe.
On 12/05/18 15:43, upsidedown@downunder.com wrote:
On Sat, 12 May 2018 06:42:19 -0700 (PDT),
gnuarm.deletethisbit@gmail.com wrote:
On Sunday, August 27, 2017 at 5:43:56 PM UTC-4, bitrex wrote:
On 08/27/2017 03:40 PM, Tim Williams wrote:
Not so bad when you've got so many to spare: example, dedicate a few
rows of cores as data routing (which can be any combination you like:
duplexed, synchronous, packetized, variable length, addressed...), and
use the remaining perimeter as your parallel processor. You might still
get dozens of cores in parallel that way, even if the utilization is
effectively maybe 20%.
Each core can "know" what the load is for the cores on its perimeter; if
some core needs to send a message to the perimeter a
best-first/greedy-search algorithm like beam search might be able to be
used to find the path where passing would cause the least disruption.
https://en.wikipedia.org/wiki/Beam_search
I know this is an old thread, but I came across it when looking for something else and had a few brain cells wakened.
Not directly related to this issues, but some recollections of
articles in electronic journals from the early 1970's.
In one article it was speculated that one day in the far future the
processor clock speed would be over 1 GHz and calculating sin/cos etc.
would be hyper fast. Apparently the editor assumed that those
functions were calculated using Taylor series. The article suggested
using the trigonometric equation
sin(a+b) = sin(a)cos(b) + cos(a)sin(b)
and doing sin(a) and cos(a) with table lookup.
The CORDIC algorithm was invented in 1956.
Two decades later implementing floating point plus
CORDIC on a 6800 was my first paid job as a
vacation student. I still have the code
On Sat, 12 May 2018 16:23:18 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:
On 12/05/18 15:43, upsidedown@downunder.com wrote:
On Sat, 12 May 2018 06:42:19 -0700 (PDT),
gnuarm.deletethisbit@gmail.com wrote:
On Sunday, August 27, 2017 at 5:43:56 PM UTC-4, bitrex wrote:
On 08/27/2017 03:40 PM, Tim Williams wrote:
Not so bad when you've got so many to spare: example, dedicate a few
rows of cores as data routing (which can be any combination you like:
duplexed, synchronous, packetized, variable length, addressed...), and
use the remaining perimeter as your parallel processor. You might still
get dozens of cores in parallel that way, even if the utilization is
effectively maybe 20%.
Each core can "know" what the load is for the cores on its perimeter; if
some core needs to send a message to the perimeter a
best-first/greedy-search algorithm like beam search might be able to be
used to find the path where passing would cause the least disruption.
https://en.wikipedia.org/wiki/Beam_search
I know this is an old thread, but I came across it when looking for something else and had a few brain cells wakened.
Not directly related to this issues, but some recollections of
articles in electronic journals from the early 1970's.
In one article it was speculated that one day in the far future the
processor clock speed would be over 1 GHz and calculating sin/cos etc.
would be hyper fast. Apparently the editor assumed that those
functions were calculated using Taylor series. The article suggested
using the trigonometric equation
sin(a+b) = sin(a)cos(b) + cos(a)sin(b)
and doing sin(a) and cos(a) with table lookup.
The CORDIC algorithm was invented in 1956.
Two decades later implementing floating point plus
CORDIC on a 6800 was my first paid job as a >> vacation student. I still have the code
On 13/05/18 21:19, John Larkin wrote:
On Sat, 12 May 2018 16:23:18 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:
On 12/05/18 15:43, upsidedown@downunder.com wrote:
On Sat, 12 May 2018 06:42:19 -0700 (PDT),
gnuarm.deletethisbit@gmail.com wrote:
On Sunday, August 27, 2017 at 5:43:56 PM UTC-4, bitrex wrote:
On 08/27/2017 03:40 PM, Tim Williams wrote:
Not so bad when you've got so many to spare: example, dedicate a few
rows of cores as data routing (which can be any combination you
like:
duplexed, synchronous, packetized, variable length,
addressed...), and
use the remaining perimeter as your parallel processor. You
might still
get dozens of cores in parallel that way, even if the utilization is
effectively maybe 20%.
Each core can "know" what the load is for the cores on its
perimeter; if
some core needs to send a message to the perimeter a
best-first/greedy-search algorithm like beam search might be able
to be
used to find the path where passing would cause the least disruption.
https://en.wikipedia.org/wiki/Beam_search
I know this is an old thread, but I came across it when looking for
something else and had a few brain cells wakened.
Not directly related to this issues, but some recollections of
articles in electronic journals from the early 1970's.
In one article it was speculated that one day in the far future the
processor clock speed would be over 1 GHz and calculating sin/cos etc.
would be hyper fast. Apparently the editor assumed that those
functions were calculated using Taylor series. The article suggested
using the trigonometric equation
sin(a+b) = sin(a)cos(b) + cos(a)sin(b)
and doing sin(a) and cos(a) with table lookup.
The CORDIC algorithm was invented in 1956.
Two decades later implementing floating point plus
CORDIC on a 6800 was my first paid job as a >> vacation student. I
still have the code
That also taught me the reason why semaphores are
necessary; my university project supervisor was
pleasantly surprised when I knew about them before
the course had been started
I wrote a preemptive multitasking RTOS for the 6800. In longhand. In
Juneau Alaska. I mailed a few sheets a day back to New Orleans, where
people punched cards for assembly. It had one bug.
My final year project was a 4TTY -> computer multiplexer,
both hardware and 6800 asm software.
I wrote an exceptionally simple "executive" that
did little more than save/restore each task's PC
and SP. It was only a few instructions.
It was a nuisance. A NOP took two microseconds. There wasn't an
instruction to push the index register onto the stack,
That was used infrequently in "user code", unlike loading
the index register from a location defined by the index
register. I used that very frequently to chain along
linked lists. When I tried to do that in the Z80 with its
IX and IY registers, it was seriously painful; so painful
that it was better to use plain old 8080 instructions
with the HL register.
My theory is that the Z80 won because of a better hardware
interface and the beguiling possibility of doing a print
statement in a single instruction. Beguiling to hardware
engineers that is, until they tried to do it in a real
system, and found all its inadequacies.
and it wouldn't
multiply, among other things.
That was rare then, but surprisingly doing it in software
was little slower than having an external hardware
multiplier chip.
Next Sunday I expect to see the world's oldest operating
computer, based on Dekatrons, plus a working example of
the first computer I used in anger, complete with 39bit
words and magnetic film peripheral complete with sprocket
holes. At the last two visits the attendant whipped out
the circuit diagrams and we poured over them together
That's my kind of museum
Plus the clunk of ASR33s is always /extremely/ evocative.
On 14.5.18 00:50, Tom Gardner wrote:
Next Sunday I expect to see the world's oldest operating
computer, based on Dekatrons, plus a working example of
the first computer I used in anger, complete with 39bit
words and magnetic film peripheral complete with sprocket
holes. At the last two visits the attendant whipped out
the circuit diagrams and we poured over them together
That's my kind of museum
Plus the clunk of ASR33s is always /extremely/ evocative.
Elliott 803 / 503?