On Wednesday, March 9, 2022 at 4:36:57 AM UTC-7, Thomas Koenig wrote:
> If you want, you can have a softcore for your CPU and define special
> instructions for your special needs. I don't think it is easy
> to modify the FPGA programming on the fly.

It depends what FPGA you use. Some use fusible links, others use
logic gates that are controlled by data stored in flip-flops. I'm thinking of
something a bit less flexible, but with wiring that is somewhat like that in
the latter type of FPGA. Thus, one doesn't have components to replace
arbitrary Boolean logic, one just makes connections between adders,
multipliers, and dividers.

Over the course of a single program, the dataflow logic would likely
get set up differently several times, because a computer program
doesn't normally consist of just one inner loop.

The idea is _not_ to have a computer designed for one "special need",
but to have a computer that does what computers do now, just faster,
due to the use of dataflow circuitry - designed to do _better_ than just
deducing data flows from regular code with a limited window, as done
in out-of-order designs.

However, I have my doubts that this idea can be made to work. Regular
FPGAs, as you suggest, do have their uses. I don't quarrel with that,
but I am looking to satisfy a different use case.

John Savard

On 3/9/22 01:32, Quadibloc wrote:
> On Sunday, March 6, 2022 at 10:50:47 AM UTC-7, John Levine wrote:
>> According to Ivan Godard <iv...@millcomputing.com>:
>>> I think the problem is really a linguistic one: our programming
>>> languages have caused us to think about our programs in control flow
>>> terms, when they are more naturally (and more efficiently) thought of
>>> in dataflow terms.
>
>> I blame von Neumann. Look at the First Draft of a Report on the EDVAC
>> and it's brutally serial, one step after another, one word at a time
>> loaded or stored from the iconoscope.
>
>> Compare it to the lovely ENIAC where you could plug anything into
>> anything else, cables permitting, and the data flowed as soon as it
>> was ready. Yeah, it was a little harder to program and only five
>> people in the world could do it, but you can't have everything.
>
> After the ENIAC, though, eventually more people learned how to
> program in dataflow terms. Because that's how analog computers
> were programmed.
>
> And what about punched-card accounting machines?
>
> Originally, the victory of the von Neumann machine came about
> for a very simple reason: such a machine required far less hardware.
> One ALU for a program of any length or complexity, instead of as many
> arithmetic stages as there were steps in the problem.
>
> But the other problem is that a lot of uses were found for computers.
> Dataflow seems to be good for one thing: turning a stack of input numbers
> into a stack of output numbers. Now that programs are written to work in
> a GUI instead of from a command line, however, a paradigm that's at least
> analogous to dataflow is needed on the highest level, instead of just in
> the innermost loops.
>
> Also, while a computer could be designed to be a dataflow engine on
> one level, there is the brutal slowness of the interface to main memory,
> to external DRAM.
>
> So it would be simple enough to design a dataflow processor. You
> put a pile of ALUs on a chip. You have a lot of switchable connections
> linking them. And you also put a pile of separate memories in the chip,
> so that you can link multiple inputs and outputs to the computation.
>
> Some of those memories could be used as look-up tables instead of
> input or output hoppers.
>
> The problem is: how useful would such a processor be? Assume it
> shares a die with a conventional processor, which is used to set it up
> for problems. How often will setting it up for a problem be faster than
> just having the serial processor do the problem?
>
> I have tried to think of a way to define a dataflow instruction for
> what is otherwise a conventional processor. Basically, the instruction
> performs a vector operation, but with multiple opcodes, with all the
> data forwarding specified.
>
> John Savard

For an attempt at a dataflow co-processor to an Arm-9, see
<www.microarch.org/micro36/html/pdf/may-ReconfigStreaming.pdf>
I was the lead architect. It obviously was not successful but we
did have working silicon. The memory system we had to use was way
too slow to keep up.

brian

On 3/8/2022 11:32 PM, Quadibloc wrote:
> On Sunday, March 6, 2022 at 10:50:47 AM UTC-7, John Levine wrote:
>> According to Ivan Godard <iv...@millcomputing.com>:
>>> I think the problem is really a linguistic one: our programming
>>> languages have caused us to think about our programs in control flow
>>> terms, when they are more naturally (and more efficiently) thought of
>>> in dataflow terms.
>
>> I blame von Neumann. Look at the First Draft of a Report on the EDVAC
>> and it's brutally serial, one step after another, one word at a time
>> loaded or stored from the iconoscope.
>
>> Compare it to the lovely ENIAC where you could plug anything into
>> anything else, cables permitting, and the data flowed as soon as it
>> was ready. Yeah, it was a little harder to program and only five
>> people in the world could do it, but you can't have everything.
>
> After the ENIAC, though, eventually more people learned how to
> program in dataflow terms. Because that's how analog computers
> were programmed.
>
> And what about punched-card accounting machines?
>
> Originally, the victory of the von Neumann machine came about
> for a very simple reason: such a machine required far less hardware.
> One ALU for a program of any length or complexity, instead of as many
> arithmetic stages as there were steps in the problem.
>
> But the other problem is that a lot of uses were found for computers.
> Dataflow seems to be good for one thing: turning a stack of input numbers
> into a stack of output numbers. Now that programs are written to work in
> a GUI instead of from a command line, however, a paradigm that's at least
> analogous to dataflow is needed on the highest level, instead of just in
> the innermost loops.
>
> Also, while a computer could be designed to be a dataflow engine on
> one level, there is the brutal slowness of the interface to main memory,
> to external DRAM.
>
> So it would be simple enough to design a dataflow processor. You
> put a pile of ALUs on a chip. You have a lot of switchable connections
> linking them. And you also put a pile of separate memories in the chip,
> so that you can link multiple inputs and outputs to the computation.
>
> Some of those memories could be used as look-up tables instead of
> input or output hoppers.

Sounds a lot like the data plane of a network control processor.

> The problem is: how useful would such a processor be? Assume it
> shares a die with a conventional processor, which is used to set it up
> for problems. How often will setting it up for a problem be faster than
> just having the serial processor do the problem?
>
> I have tried to think of a way to define a dataflow instruction for
> what is otherwise a conventional processor. Basically, the instruction
> performs a vector operation, but with multiple opcodes, with all the
> data forwarding specified.
>
> John Savard

On Wednesday, March 9, 2022 at 1:33:02 AM UTC-6, Quadibloc wrote:
> On Sunday, March 6, 2022 at 10:50:47 AM UTC-7, John Levine wrote:
> > According to Ivan Godard <iv...@millcomputing.com>:
> > >I think the problem is really a linguistic one: our programming
> > >languages have caused us to think about our programs in control flow
> > >terms, when they are more naturally (and more efficiently) thought of
> > >in dataflow terms.
>
> > I blame von Neumann. Look at the First Draft of a Report on the EDVAC
> > and it's brutally serial, one step after another, one word at a time
> > loaded or stored from the iconoscope.
>
> > Compare it to the lovely ENIAC where you could plug anything into
> > anything else, cables permitting, and the data flowed as soon as it
> > was ready. Yeah, it was a little harder to program and only five
> > people in the world could do it, but you can't have everything.
> After the ENIAC, though, eventually more people learned how to
> program in dataflow terms. Because that's how analog computers
> were programmed.
>
> And what about punched-card accounting machines?
>
> Originally, the victory of the von Neumann machine came about
> for a very simple reason: such a machine required far less hardware.
> One ALU for a program of any length or complexity, instead of as many
> arithmetic stages as there were steps in the problem.
>
> But the other problem is that a lot of uses were found for computers.
> Dataflow seems to be good for one thing: turning a stack of input numbers
> into a stack of output numbers. Now that programs are written to work in
> a GUI instead of from a command line, however, a paradigm that's at least
> analogous to dataflow is needed on the highest level, instead of just in
> the innermost loops.
>
> Also, while a computer could be designed to be a dataflow engine on
> one level, there is the brutal slowness of the interface to main memory,
> to external DRAM.
>
> So it would be simple enough to design a dataflow processor. You
> put a pile of ALUs on a chip. You have a lot of switchable connections
> linking them. And you also put a pile of separate memories in the chip,
> so that you can link multiple inputs and outputs to the computation.
<
The problem with data flow is managing to constrain the width of
execution congruent with the width of the resources. While conventional
machine struggle to find parallelism, data flow machines struggled to
bound parallelism so as to avoid overflowing the "reservation stations"
of the machine.
>
> Some of those memories could be used as look-up tables instead of
> input or output hoppers.
>
> The problem is: how useful would such a processor be? Assume it
> shares a die with a conventional processor, which is used to set it up
> for problems. How often will setting it up for a problem be faster than
> just having the serial processor do the problem?
>
> I have tried to think of a way to define a dataflow instruction for
> what is otherwise a conventional processor. Basically, the instruction
> performs a vector operation, but with multiple opcodes, with all the
> data forwarding specified.
>
> John Savard

On 3/9/2022 8:47 AM, Quadibloc wrote:
> On Wednesday, March 9, 2022 at 4:36:57 AM UTC-7, Thomas Koenig wrote:
>
>> If you want, you can have a softcore for your CPU and define special
>> instructions for your special needs. I don't think it is easy
>> to modify the FPGA programming on the fly.
>
> It depends what FPGA you use. Some use fusible links, others use
> logic gates that are controlled by data stored in flip-flops. I'm thinking of
> something a bit less flexible, but with wiring that is somewhat like that in
> the latter type of FPGA. Thus, one doesn't have components to replace
> arbitrary Boolean logic, one just makes connections between adders,
> multipliers, and dividers.
>

Most are SRAM based, some are Flash based.

Fusible links seems to be more a thing for one-time-programmable PAL and
CPLD devices.

> Over the course of a single program, the dataflow logic would likely
> get set up differently several times, because a computer program
> doesn't normally consist of just one inner loop.
>
> The idea is _not_ to have a computer designed for one "special need",
> but to have a computer that does what computers do now, just faster,
> due to the use of dataflow circuitry - designed to do _better_ than just
> deducing data flows from regular code with a limited window, as done
> in out-of-order designs.
>
> However, I have my doubts that this idea can be made to work. Regular
> FPGAs, as you suggest, do have their uses. I don't quarrel with that,
> but I am looking to satisfy a different use case.
>

I guess it could be possible to make an FPGA that, instead of being
built around 1-bit interconnections, is mostly 4 and 8 bit
interconnections (Say, 4-bit mostly for local connections, and 8-bit for
longer-distance pathways).

This could potentially be used to make the routing cheaper, though would
be much better suited for larger coarse-grain signals, rather than
fine-grain signals.

So, LUT elements are primarily 8->4 bit, ADD units are 8+8=>8 (With
CarryIn/CarryOut).

Adders could be in groups of 4, so that they can use 4b inputs/outputs
for carry signaling, with "bit-transform" units placed in the "carry-in
/ carry-out" paths to allow readily feeding the carry signals back into
to other adders within the same unit (this unit being usable as a
32+32->32 ADD, with 1-bit left for carry-in / carry-out).

Ideally, the unit could also be configured for SUB/AND/OR/XOR as well.

Would be less efficient in some ways, things like bit-shuffling, etc,
would now require using LUTs, and emulating smaller LUTs would be
inefficient.

It is likely that, along with LUT and FF elements, one would also need
bit-transform elements 2x4->2x4 with a configurable mapping between the
input and output bits, likely glued onto the output side of each LUT
(between the LUT and a 4b FF).

The bit-transform elements could allow for more efficiently emulating
smaller LUTs, like 4->1 or 4->2 (and would operate in a similar way to
an SSE shuffle with two inputs and two outputs).

Would likely need to widen DSPs to 20-bit inputs (A20*B20+C48), or
narrow to 16 (A16*B16+C40).

Or, maybe a DSP unit that could be configured as, say:
Two 16 or 20 bit multiply MUL or MAC units;
One 32-bit MUL;
One 32-bit FMUL or FMAC.

Though, another option would be to use a mixed approach, with mostly
1-bit local routing (would function more like in existing FPGAs), but
then use coarser grain 4 and 8 bit signaling for moving signals between
distant parts of the FPGA.

Say, for example, each group of 16 or 64 CLBs has internal 1-bit
routing, with a 4-bit interconnect to other groups of CLBs.

Some of this is based on the thought that larger multi-bit signals and
operations tend to be a lot more common than 1-bit operations, that some
loss of efficiency for 1-bit operations could be acceptable.

....

On Wednesday, March 9, 2022 at 2:17:47 PM UTC-6, BGB wrote:
> On 3/9/2022 8:47 AM, Quadibloc wrote:
> > On Wednesday, March 9, 2022 at 4:36:57 AM UTC-7, Thomas Koenig wrote:
> >
> >> If you want, you can have a softcore for your CPU and define special
> >> instructions for your special needs. I don't think it is easy
> >> to modify the FPGA programming on the fly.
> >
> > It depends what FPGA you use. Some use fusible links, others use
> > logic gates that are controlled by data stored in flip-flops. I'm thinking of
> > something a bit less flexible, but with wiring that is somewhat like that in
> > the latter type of FPGA. Thus, one doesn't have components to replace
> > arbitrary Boolean logic, one just makes connections between adders,
> > multipliers, and dividers.
> >
> Most are SRAM based, some are Flash based.
>
> Fusible links seems to be more a thing for one-time-programmable PAL and
> CPLD devices.
> > Over the course of a single program, the dataflow logic would likely
> > get set up differently several times, because a computer program
> > doesn't normally consist of just one inner loop.
> >
> > The idea is _not_ to have a computer designed for one "special need",
> > but to have a computer that does what computers do now, just faster,
> > due to the use of dataflow circuitry - designed to do _better_ than just
> > deducing data flows from regular code with a limited window, as done
> > in out-of-order designs.
> >
> > However, I have my doubts that this idea can be made to work. Regular
> > FPGAs, as you suggest, do have their uses. I don't quarrel with that,
> > but I am looking to satisfy a different use case.
> >
> I guess it could be possible to make an FPGA that, instead of being
> built around 1-bit interconnections, is mostly 4 and 8 bit
> interconnections (Say, 4-bit mostly for local connections, and 8-bit for
> longer-distance pathways).
>
>
> This could potentially be used to make the routing cheaper, though would
> be much better suited for larger coarse-grain signals, rather than
> fine-grain signals.
>
>
> So, LUT elements are primarily 8->4 bit, ADD units are 8+8=>8 (With
> CarryIn/CarryOut).
>
> Adders could be in groups of 4, so that they can use 4b inputs/outputs
> for carry signaling, with "bit-transform" units placed in the "carry-in
> / carry-out" paths to allow readily feeding the carry signals back into
> to other adders within the same unit (this unit being usable as a
> 32+32->32 ADD, with 1-bit left for carry-in / carry-out).
<
Adders should be built in units of 9-bits. The "extra bit" can be used to
clip-carry (inputs = 0 and 0), propagate carry (1 0 or 0 1), or insert carry
(1 1). Thus, you can perform SIMD arithmetic in a std integer adder.
>
> Ideally, the unit could also be configured for SUB/AND/OR/XOR as well.
>
>
>
> Would be less efficient in some ways, things like bit-shuffling, etc,
> would now require using LUTs, and emulating smaller LUTs would be
> inefficient.
>
> It is likely that, along with LUT and FF elements, one would also need
> bit-transform elements 2x4->2x4 with a configurable mapping between the
> input and output bits, likely glued onto the output side of each LUT
> (between the LUT and a 4b FF).
<
4×4 or 8×8 bit-matrix-multiply
>
> The bit-transform elements could allow for more efficiently emulating
> smaller LUTs, like 4->1 or 4->2 (and would operate in a similar way to
> an SSE shuffle with two inputs and two outputs).
>
>
> Would likely need to widen DSPs to 20-bit inputs (A20*B20+C48), or
> narrow to 16 (A16*B16+C40).
>
> Or, maybe a DSP unit that could be configured as, say:
> Two 16 or 20 bit multiply MUL or MAC units;
> One 32-bit MUL;
> One 32-bit FMUL or FMAC.
>
>
> Though, another option would be to use a mixed approach, with mostly
> 1-bit local routing (would function more like in existing FPGAs), but
> then use coarser grain 4 and 8 bit signaling for moving signals between
> distant parts of the FPGA.
>
> Say, for example, each group of 16 or 64 CLBs has internal 1-bit
> routing, with a 4-bit interconnect to other groups of CLBs.
>
>
>
> Some of this is based on the thought that larger multi-bit signals and
> operations tend to be a lot more common than 1-bit operations, that some
> loss of efficiency for 1-bit operations could be acceptable.
>
> ...

On 3/9/2022 2:36 PM, MitchAlsup wrote:
> On Wednesday, March 9, 2022 at 2:17:47 PM UTC-6, BGB wrote:
>> On 3/9/2022 8:47 AM, Quadibloc wrote:
>>> On Wednesday, March 9, 2022 at 4:36:57 AM UTC-7, Thomas Koenig wrote:
>>>
>>>> If you want, you can have a softcore for your CPU and define special
>>>> instructions for your special needs. I don't think it is easy
>>>> to modify the FPGA programming on the fly.
>>>
>>> It depends what FPGA you use. Some use fusible links, others use
>>> logic gates that are controlled by data stored in flip-flops. I'm thinking of
>>> something a bit less flexible, but with wiring that is somewhat like that in
>>> the latter type of FPGA. Thus, one doesn't have components to replace
>>> arbitrary Boolean logic, one just makes connections between adders,
>>> multipliers, and dividers.
>>>
>> Most are SRAM based, some are Flash based.
>>
>> Fusible links seems to be more a thing for one-time-programmable PAL and
>> CPLD devices.
>>> Over the course of a single program, the dataflow logic would likely
>>> get set up differently several times, because a computer program
>>> doesn't normally consist of just one inner loop.
>>>
>>> The idea is _not_ to have a computer designed for one "special need",
>>> but to have a computer that does what computers do now, just faster,
>>> due to the use of dataflow circuitry - designed to do _better_ than just
>>> deducing data flows from regular code with a limited window, as done
>>> in out-of-order designs.
>>>
>>> However, I have my doubts that this idea can be made to work. Regular
>>> FPGAs, as you suggest, do have their uses. I don't quarrel with that,
>>> but I am looking to satisfy a different use case.
>>>
>> I guess it could be possible to make an FPGA that, instead of being
>> built around 1-bit interconnections, is mostly 4 and 8 bit
>> interconnections (Say, 4-bit mostly for local connections, and 8-bit for
>> longer-distance pathways).
>>

Granted, this does carry the unverified assumption that 4b or 8b paths
would be cheaper than a bunch of independent 1-bit paths.

The number of signal wires would be similar, as would the number of
transistors needed for the crossbar itself. It would mostly effect to
the cost of configuring the crossbar (eg: controlling 4 or 8 MOSFETs
with a single input signal).

It would mostly reduce the number of SRAM cells, and the number of
signals being used in the crossbar for configuring said SRAM cells.

>>
>> This could potentially be used to make the routing cheaper, though would
>> be much better suited for larger coarse-grain signals, rather than
>> fine-grain signals.
>>
>>
>> So, LUT elements are primarily 8->4 bit, ADD units are 8+8=>8 (With
>> CarryIn/CarryOut).
>>
>> Adders could be in groups of 4, so that they can use 4b inputs/outputs
>> for carry signaling, with "bit-transform" units placed in the "carry-in
>> / carry-out" paths to allow readily feeding the carry signals back into
>> to other adders within the same unit (this unit being usable as a
>> 32+32->32 ADD, with 1-bit left for carry-in / carry-out).
> <
> Adders should be built in units of 9-bits. The "extra bit" can be used to
> clip-carry (inputs = 0 and 0), propagate carry (1 0 or 0 1), or insert carry
> (1 1). Thus, you can perform SIMD arithmetic in a std integer adder.

Issue is 9b would not fit into a pathway build on 4-bit interconnects.

But, ideally, one wants to minimize the number of 4-bit paths being used
to carry 1 or 2 bit signals, hence the idea of a bit-transform.

>>
>> Ideally, the unit could also be configured for SUB/AND/OR/XOR as well.
>>
>>
>>
>> Would be less efficient in some ways, things like bit-shuffling, etc,
>> would now require using LUTs, and emulating smaller LUTs would be
>> inefficient.
>>
>> It is likely that, along with LUT and FF elements, one would also need
>> bit-transform elements 2x4->2x4 with a configurable mapping between the
>> input and output bits, likely glued onto the output side of each LUT
>> (between the LUT and a 4b FF).
> <
> 4×4 or 8×8 bit-matrix-multiply

Yeah, could probably be done this way.

An 8x8 multiply could do it in one step, but would need 64 control bits.
In effect it reduces to a bunch of AND and OR operations.

The number of control bits would be higher with this than doing it SSE
style, but this could also implement a few simple logic operations
between groups of bits.

....

>>
>> The bit-transform elements could allow for more efficiently emulating
>> smaller LUTs, like 4->1 or 4->2 (and would operate in a similar way to
>> an SSE shuffle with two inputs and two outputs).
>>
>>
>> Would likely need to widen DSPs to 20-bit inputs (A20*B20+C48), or
>> narrow to 16 (A16*B16+C40).
>>
>> Or, maybe a DSP unit that could be configured as, say:
>> Two 16 or 20 bit multiply MUL or MAC units;
>> One 32-bit MUL;
>> One 32-bit FMUL or FMAC.
>>
>>
>> Though, another option would be to use a mixed approach, with mostly
>> 1-bit local routing (would function more like in existing FPGAs), but
>> then use coarser grain 4 and 8 bit signaling for moving signals between
>> distant parts of the FPGA.
>>
>> Say, for example, each group of 16 or 64 CLBs has internal 1-bit
>> routing, with a 4-bit interconnect to other groups of CLBs.
>>
>>
>>
>> Some of this is based on the thought that larger multi-bit signals and
>> operations tend to be a lot more common than 1-bit operations, that some
>> loss of efficiency for 1-bit operations could be acceptable.
>>
>> ...

Terje Mathisen <terje.mathisen@tmsw.no> writes:

> Tim Rentsch wrote:
>
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>
>>> Tim Rentsch wrote:
>>>
>>>> Ivan Godard <ivan@millcomputing.com> writes:
>>>>
>>>> [...]
>>>>
>>>>> I think the problem is really a linguistic one: our programming
>>>>> languages have caused us to think about our programs in control
>>>>> flow terms, [...]
>>>>
>>>> Some of us. Not everyone, fortunately.
>>>
>>> I tend to think much more in data flow terms, as I've written before:
>>>
>>> An optimal program is like a creek finding its path down from the
>>> mountain, always searching for the path of least resistance.
>>
>> It's an interesting simile. Note by the way that creeks are
>> greedy algorithms, in the sense of being only locally optimal,
>> not necessarily globally optimal.
>>
>> To me the more interesting question is how does this perspective
>> affect how the code looks? If reading your programs, would I see
>> something that looks pretty much like other imperative code, or
>> would there be some distinguishing characteristics that would
>> indicate your different thought mode? Can you say anything about
>> what those characteristics might be? Or perhaps give an example
>> or two? (Short is better if that is feasible.)
>
> First example: Use (very) small lookup tables to get rid of branches,
> typically trying to turn code state machines into data state
> machines. This is driven by the fact that modern CPUs are much better
> at dependent loads than unpredictable branches.
>
> I typically try to write code that can run in SIMD mode, i.e. using
> tables/branchless/predicated ops to handle any single-lane alternate
> paths.
>
> Such code can also much more often scale across multiple cores/systems
> even if that means that I have to do some redundant work across the
> boundaries. I.e. when I process lidar data I can make the problem
> almost embarrasingly parallelizable by splitting the input into tiles
> with 35-50m overlap: This is sufficient to effectively eliminate all
> edge artifacts when I generate contours and vegetation
> classifications.

Interesting. Thank you for the examples.

> The most fun is when I find ways to remove all internal branching
> related to exceptional data, i.e. anything which can impede that
> nicely flowing stream of water going downhill.

In that sentence the word "which" should be "that". The reason is
"that" is restrictive, whereas "which" in non-restrictive. In
other words you mean the rest of the sentence after "which" to
constrain the word "anything", i.e., to restrict what is covered.
This distinction is important in technical writing; unfortunately
even native speakers sometimes get it wrong.

On Wednesday, March 9, 2022 at 3:01:55 PM UTC-6, BGB wrote:
> On 3/9/2022 2:36 PM, MitchAlsup wrote:
> > On Wednesday, March 9, 2022 at 2:17:47 PM UTC-6, BGB wrote:
> >> On 3/9/2022 8:47 AM, Quadibloc wrote:
> >>> On Wednesday, March 9, 2022 at 4:36:57 AM UTC-7, Thomas Koenig wrote:
> >>>
> >>>> If you want, you can have a softcore for your CPU and define special
> >>>> instructions for your special needs. I don't think it is easy
> >>>> to modify the FPGA programming on the fly.
> >>>
> >>> It depends what FPGA you use. Some use fusible links, others use
> >>> logic gates that are controlled by data stored in flip-flops. I'm thinking of
> >>> something a bit less flexible, but with wiring that is somewhat like that in
> >>> the latter type of FPGA. Thus, one doesn't have components to replace
> >>> arbitrary Boolean logic, one just makes connections between adders,
> >>> multipliers, and dividers.
> >>>
> >> Most are SRAM based, some are Flash based.
> >>
> >> Fusible links seems to be more a thing for one-time-programmable PAL and
> >> CPLD devices.
> >>> Over the course of a single program, the dataflow logic would likely
> >>> get set up differently several times, because a computer program
> >>> doesn't normally consist of just one inner loop.
> >>>
> >>> The idea is _not_ to have a computer designed for one "special need",
> >>> but to have a computer that does what computers do now, just faster,
> >>> due to the use of dataflow circuitry - designed to do _better_ than just
> >>> deducing data flows from regular code with a limited window, as done
> >>> in out-of-order designs.
> >>>
> >>> However, I have my doubts that this idea can be made to work. Regular
> >>> FPGAs, as you suggest, do have their uses. I don't quarrel with that,
> >>> but I am looking to satisfy a different use case.
> >>>
> >> I guess it could be possible to make an FPGA that, instead of being
> >> built around 1-bit interconnections, is mostly 4 and 8 bit
> >> interconnections (Say, 4-bit mostly for local connections, and 8-bit for
> >> longer-distance pathways).
> >>
> Granted, this does carry the unverified assumption that 4b or 8b paths
> would be cheaper than a bunch of independent 1-bit paths.
>
>
> The number of signal wires would be similar, as would the number of
> transistors needed for the crossbar itself. It would mostly effect to
> the cost of configuring the crossbar (eg: controlling 4 or 8 MOSFETs
> with a single input signal).
>
> It would mostly reduce the number of SRAM cells, and the number of
> signals being used in the crossbar for configuring said SRAM cells.
> >>
> >> This could potentially be used to make the routing cheaper, though would
> >> be much better suited for larger coarse-grain signals, rather than
> >> fine-grain signals.
> >>
> >>
> >> So, LUT elements are primarily 8->4 bit, ADD units are 8+8=>8 (With
> >> CarryIn/CarryOut).
> >>
> >> Adders could be in groups of 4, so that they can use 4b inputs/outputs
> >> for carry signaling, with "bit-transform" units placed in the "carry-in
> >> / carry-out" paths to allow readily feeding the carry signals back into
> >> to other adders within the same unit (this unit being usable as a
> >> 32+32->32 ADD, with 1-bit left for carry-in / carry-out).
> > <
> > Adders should be built in units of 9-bits. The "extra bit" can be used to
> > clip-carry (inputs = 0 and 0), propagate carry (1 0 or 0 1), or insert carry
> > (1 1). Thus, you can perform SIMD arithmetic in a std integer adder.
> Issue is 9b would not fit into a pathway build on 4-bit interconnects.
>
> But, ideally, one wants to minimize the number of 4-bit paths being used
> to carry 1 or 2 bit signals, hence the idea of a bit-transform.
<
A pair of 4-bit channels with a 1-bit separator makes one 9-bit channel.
A single 8-bit channel with a 1-bit separator makes 1 9-bit channel.
<
MIPS R3000 used this an you can see it in the die photo. The other parts
of the channel are used to Vdd/Gnd ties and on-die capacitors. We contemplated
using a channel such as this for signal repeaters (double inverters back to back)
for wires jumping over the "data path" at 35u.
> >>
> >> Ideally, the unit could also be configured for SUB/AND/OR/XOR as well.
> >>
> >>
> >>
> >> Would be less efficient in some ways, things like bit-shuffling, etc,
> >> would now require using LUTs, and emulating smaller LUTs would be
> >> inefficient.
> >>
> >> It is likely that, along with LUT and FF elements, one would also need
> >> bit-transform elements 2x4->2x4 with a configurable mapping between the
> >> input and output bits, likely glued onto the output side of each LUT
> >> (between the LUT and a 4b FF).
> > <
> > 4×4 or 8×8 bit-matrix-multiply
> Yeah, could probably be done this way.
>
> An 8x8 multiply could do it in one step, but would need 64 control bits.
> In effect it reduces to a bunch of AND and OR operations.
>
> The number of control bits would be higher with this than doing it SSE
> style, but this could also implement a few simple logic operations
> between groups of bits.
<
You started with configurable mappings. Many of these use constants
as one input of the BMM.
>
> ...
> >>
> >> The bit-transform elements could allow for more efficiently emulating
> >> smaller LUTs, like 4->1 or 4->2 (and would operate in a similar way to
> >> an SSE shuffle with two inputs and two outputs).
> >>
> >>
> >> Would likely need to widen DSPs to 20-bit inputs (A20*B20+C48), or
> >> narrow to 16 (A16*B16+C40).
> >>
> >> Or, maybe a DSP unit that could be configured as, say:
> >> Two 16 or 20 bit multiply MUL or MAC units;
> >> One 32-bit MUL;
> >> One 32-bit FMUL or FMAC.
> >>
> >>
> >> Though, another option would be to use a mixed approach, with mostly
> >> 1-bit local routing (would function more like in existing FPGAs), but
> >> then use coarser grain 4 and 8 bit signaling for moving signals between
> >> distant parts of the FPGA.
> >>
> >> Say, for example, each group of 16 or 64 CLBs has internal 1-bit
> >> routing, with a 4-bit interconnect to other groups of CLBs.
> >>
> >>
> >>
> >> Some of this is based on the thought that larger multi-bit signals and
> >> operations tend to be a lot more common than 1-bit operations, that some
> >> loss of efficiency for 1-bit operations could be acceptable.
> >>
> >> ...

Tim Rentsch wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>
>> Tim Rentsch wrote:
>>
>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>
>>>> Tim Rentsch wrote:
>>>>
>>>>> Ivan Godard <ivan@millcomputing.com> writes:
>>>>>
>>>>> [...]
>>>>>
>>>>>> I think the problem is really a linguistic one: our programming
>>>>>> languages have caused us to think about our programs in control
>>>>>> flow terms, [...]
>>>>>
>>>>> Some of us. Not everyone, fortunately.
>>>>
>>>> I tend to think much more in data flow terms, as I've written before:
>>>>
>>>> An optimal program is like a creek finding its path down from the
>>>> mountain, always searching for the path of least resistance.
>>>
>>> It's an interesting simile. Note by the way that creeks are
>>> greedy algorithms, in the sense of being only locally optimal,
>>> not necessarily globally optimal.
>>>
>>> To me the more interesting question is how does this perspective
>>> affect how the code looks? If reading your programs, would I see
>>> something that looks pretty much like other imperative code, or
>>> would there be some distinguishing characteristics that would
>>> indicate your different thought mode? Can you say anything about
>>> what those characteristics might be? Or perhaps give an example
>>> or two? (Short is better if that is feasible.)
>>
>> First example: Use (very) small lookup tables to get rid of branches,
>> typically trying to turn code state machines into data state
>> machines. This is driven by the fact that modern CPUs are much better
>> at dependent loads than unpredictable branches.
>>
>> I typically try to write code that can run in SIMD mode, i.e. using
>> tables/branchless/predicated ops to handle any single-lane alternate
>> paths.
>>
>> Such code can also much more often scale across multiple cores/systems
>> even if that means that I have to do some redundant work across the
>> boundaries. I.e. when I process lidar data I can make the problem
>> almost embarrasingly parallelizable by splitting the input into tiles
>> with 35-50m overlap: This is sufficient to effectively eliminate all
>> edge artifacts when I generate contours and vegetation
>> classifications.
>
> Interesting. Thank you for the examples.

The core idea there is that it can often make sense to do extra work as
long as that removes the cost of maintaining exact boundaries. A similar
idea was the building block for my julian day to Y-M-D conversion:

The math to do so is quite complicated, so instead I make a very quick
approximate guess and do the reverse (very fast!) calculation which ends
with a branchless adjustment if the guess was off-by-one.
>
>> The most fun is when I find ways to remove all internal branching
>> related to exceptional data, i.e. anything which can impede that
>> nicely flowing stream of water going downhill.
>
> In that sentence the word "which" should be "that". The reason is
> "that" is restrictive, whereas "which" in non-restrictive. In
> other words you mean the rest of the sentence after "which" to
> constrain the word "anything", i.e., to restrict what is covered.
> This distinction is important in technical writing; unfortunately
> even native speakers sometimes get it wrong.
>

OK, that is subtle but noted!

I'll hide behind my standard "I only started to learn English in 5th
grade" excuse. :-)

My own kids started in 1st or 2nd grade, but I'll claim that they became
fluent over a couple of years when I read Harry Potter to them every
evening.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Terje Mathisen <terje.mathisen@tmsw.no> writes:

> Tim Rentsch wrote:
>
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>
>>> Tim Rentsch wrote:
>>>
>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>
>>>>> Tim Rentsch wrote:
>>>>>
>>>>>> Ivan Godard <ivan@millcomputing.com> writes:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> I think the problem is really a linguistic one: our programming
>>>>>>> languages have caused us to think about our programs in control
>>>>>>> flow terms, [...]
>>>>>>
>>>>>> Some of us. Not everyone, fortunately.
>>>>>
>>>>> I tend to think much more in data flow terms, as I've written before:
>>>>>
>>>>> An optimal program is like a creek finding its path down from the
>>>>> mountain, always searching for the path of least resistance.
>>>>
>>>> It's an interesting simile. Note by the way that creeks are
>>>> greedy algorithms, in the sense of being only locally optimal,
>>>> not necessarily globally optimal.
>>>>
>>>> To me the more interesting question is how does this perspective
>>>> affect how the code looks? If reading your programs, would I see
>>>> something that looks pretty much like other imperative code, or
>>>> would there be some distinguishing characteristics that would
>>>> indicate your different thought mode? Can you say anything about
>>>> what those characteristics might be? Or perhaps give an example
>>>> or two? (Short is better if that is feasible.)
>>>
>>> First example: Use (very) small lookup tables to get rid of branches,
>>> typically trying to turn code state machines into data state
>>> machines. This is driven by the fact that modern CPUs are much better
>>> at dependent loads than unpredictable branches.
>>>
>>> I typically try to write code that can run in SIMD mode, i.e. using
>>> tables/branchless/predicated ops to handle any single-lane alternate
>>> paths.
>>>
>>> Such code can also much more often scale across multiple cores/systems
>>> even if that means that I have to do some redundant work across the
>>> boundaries. I.e. when I process lidar data I can make the problem
>>> almost embarrasingly parallelizable by splitting the input into tiles
>>> with 35-50m overlap: This is sufficient to effectively eliminate all
>>> edge artifacts when I generate contours and vegetation
>>> classifications.
>>
>> Interesting. Thank you for the examples.
>
> The core idea there is that it can often make sense to do extra work
> as long as that removes the cost of maintaining exact boundaries. A
> similar idea was the building block for my julian day to Y-M-D
> conversion:
>
> The math to do so is quite complicated, so instead I make a very quick
> approximate guess and do the reverse (very fast!) calculation which
> ends with a branchless adjustment if the guess was off-by-one.

I am intrigued. Would you mind sharing the code (either posting
or sending to me via email, whichever you think more appropriate)?

>>> The most fun is when I find ways to remove all internal branching
>>> related to exceptional data, i.e. anything which can impede that
>>> nicely flowing stream of water going downhill.
>>
>> In that sentence the word "which" should be "that". The reason is
>> "that" is restrictive, whereas "which" in non-restrictive. In
>> other words you mean the rest of the sentence after "which" to
>> constrain the word "anything", i.e., to restrict what is covered.
>> This distinction is important in technical writing; unfortunately
>> even native speakers sometimes get it wrong.
>
> OK, that is subtle but noted!
>
> I'll hide behind my standard "I only started to learn English in 5th
> grade" excuse. :-)

No excuse needed. I routinely give such comments to people whose
first language is other than English, not with the intention of
faulting a bad usage but with the idea of helping them better
learn the subtleties and bear traps of English. If anyone should
give an excuse, I should, because my own other-language skills are
so limited. I admire anyone who speaks more than one language, as
I have found it very very difficult to do so.

On 10 Mar 2022, Terje Mathisen wrote
(in article <t0ct7p$muk$1@gioia.aioe.org>):

> Tim Rentsch wrote:
> > Terje Mathisen<terje.mathisen@tmsw.no> writes:
> > > The most fun is when I find ways to remove all internal branching
> > > related to exceptional data, i.e. anything which can impede that
> > > nicely flowing stream of water going downhill.
> >
> > In that sentence the word "which" should be "that". The reason is
> > "that" is restrictive, whereas "which" in non-restrictive. In
> > other words you mean the rest of the sentence after "which" to
> > constrain the word "anything", i.e., to restrict what is covered.
> > This distinction is important in technical writing; unfortunately
> > even native speakers sometimes get it wrong.
>
> OK, that is subtle but noted!
>
> I'll hide behind my standard "I only started to learn English in 5th
> grade" excuse. :-)

You have no need of an excuse, because your original wording was correct,
and is exactly how most British English users would put it.

Rentsch is wrong to think that using 'that' means anything different.
His claim comes straight out of Strunk & White's usage guide,
which has been debunked by English grammar experts, such as Geoff Pullum.

I personally prefer 'that' to 'which' in restrictive clauses,
but that is a matter of aesthetics, not grammatical correctness.
--
Bill Findlay

Tim Rentsch wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>
>> Tim Rentsch wrote:
>>
>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>
>>>> Tim Rentsch wrote:
>>>>
>>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>>
>>>>>> Tim Rentsch wrote:
>>>>>>
>>>>>>> Ivan Godard <ivan@millcomputing.com> writes:
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>> I think the problem is really a linguistic one: our programming
>>>>>>>> languages have caused us to think about our programs in control
>>>>>>>> flow terms, [...]
>>>>>>>
>>>>>>> Some of us. Not everyone, fortunately.
>>>>>>
>>>>>> I tend to think much more in data flow terms, as I've written before:
>>>>>>
>>>>>> An optimal program is like a creek finding its path down from the
>>>>>> mountain, always searching for the path of least resistance.
>>>>>
>>>>> It's an interesting simile. Note by the way that creeks are
>>>>> greedy algorithms, in the sense of being only locally optimal,
>>>>> not necessarily globally optimal.
>>>>>
>>>>> To me the more interesting question is how does this perspective
>>>>> affect how the code looks? If reading your programs, would I see
>>>>> something that looks pretty much like other imperative code, or
>>>>> would there be some distinguishing characteristics that would
>>>>> indicate your different thought mode? Can you say anything about
>>>>> what those characteristics might be? Or perhaps give an example
>>>>> or two? (Short is better if that is feasible.)
>>>>
>>>> First example: Use (very) small lookup tables to get rid of branches,
>>>> typically trying to turn code state machines into data state
>>>> machines. This is driven by the fact that modern CPUs are much better
>>>> at dependent loads than unpredictable branches.
>>>>
>>>> I typically try to write code that can run in SIMD mode, i.e. using
>>>> tables/branchless/predicated ops to handle any single-lane alternate
>>>> paths.
>>>>
>>>> Such code can also much more often scale across multiple cores/systems
>>>> even if that means that I have to do some redundant work across the
>>>> boundaries. I.e. when I process lidar data I can make the problem
>>>> almost embarrasingly parallelizable by splitting the input into tiles
>>>> with 35-50m overlap: This is sufficient to effectively eliminate all
>>>> edge artifacts when I generate contours and vegetation
>>>> classifications.
>>>
>>> Interesting. Thank you for the examples.
>>
>> The core idea there is that it can often make sense to do extra work
>> as long as that removes the cost of maintaining exact boundaries. A
>> similar idea was the building block for my julian day to Y-M-D
>> conversion:
>>
>> The math to do so is quite complicated, so instead I make a very quick
>> approximate guess and do the reverse (very fast!) calculation which
>> ends with a branchless adjustment if the guess was off-by-one.
>
> I am intrigued. Would you mind sharing the code (either posting
> or sending to me via email, whichever you think more appropriate)?
>
>>>> The most fun is when I find ways to remove all internal branching
>>>> related to exceptional data, i.e. anything which can impede that
>>>> nicely flowing stream of water going downhill.
>>>
>>> In that sentence the word "which" should be "that". The reason is
>>> "that" is restrictive, whereas "which" in non-restrictive. In
>>> other words you mean the rest of the sentence after "which" to
>>> constrain the word "anything", i.e., to restrict what is covered.
>>> This distinction is important in technical writing; unfortunately
>>> even native speakers sometimes get it wrong.
>>
>> OK, that is subtle but noted!
>>
>> I'll hide behind my standard "I only started to learn English in 5th
>> grade" excuse. :-)
>
> No excuse needed. I routinely give such comments to people whose
> first language is other than English, not with the intention of
> faulting a bad usage but with the idea of helping them better
> learn the subtleties and bear traps of English. If anyone should
> give an excuse, I should, because my own other-language skills are
> so limited. I admire anyone who speaks more than one language, as
> I have found it very very difficult to do so.

This is actually more interesting than I immediately thought:

First, is there a difference between US and UK English here?

Looking at it now, to me using "anything which can" vs "anything that
can" does have those two different meanings: The first one is in fact
more inclusive than the second, i.e. "which" also includes stuff that
only incidentally or as a side effect cause this, while "that" implies
that it is more of a primary result.

This was actually what I was trying to express.

Regards,
Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Bill Findlay wrote:
> On 10 Mar 2022, Terje Mathisen wrote
> (in article <t0ct7p$muk$1@gioia.aioe.org>):
>
>> Tim Rentsch wrote:
>>> Terje Mathisen<terje.mathisen@tmsw.no> writes:
>>>> The most fun is when I find ways to remove all internal branching
>>>> related to exceptional data, i.e. anything which can impede that
>>>> nicely flowing stream of water going downhill.
>>>
>>> In that sentence the word "which" should be "that". The reason is
>>> "that" is restrictive, whereas "which" in non-restrictive. In
>>> other words you mean the rest of the sentence after "which" to
>>> constrain the word "anything", i.e., to restrict what is covered.
>>> This distinction is important in technical writing; unfortunately
>>> even native speakers sometimes get it wrong.
>>
>> OK, that is subtle but noted!
>>
>> I'll hide behind my standard "I only started to learn English in 5th
>> grade" excuse. :-)
>
> You have no need of an excuse, because your original wording was correct,
> and is exactly how most British English users would put it.
>
> Rentsch is wrong to think that using 'that' means anything different.
> His claim comes straight out of Strunk & White's usage guide,
> which has been debunked by English grammar experts, such as Geoff Pullum.
>
> I personally prefer 'that' to 'which' in restrictive clauses,
> but that is a matter of aesthetics, not grammatical correctness.
>
Thanks, see my previous response to Tim. :-)

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On Thursday, March 10, 2022 at 6:55:16 PM UTC+2, Bill Findlay wrote:
> On 10 Mar 2022, Terje Mathisen wrote
> (in article <t0ct7p$muk$1...@gioia.aioe.org>):
> > Tim Rentsch wrote:
> > > Terje Mathisen<terje.m...@tmsw.no> writes:
> > > > The most fun is when I find ways to remove all internal branching
> > > > related to exceptional data, i.e. anything which can impede that
> > > > nicely flowing stream of water going downhill.
> > >
> > > In that sentence the word "which" should be "that". The reason is
> > > "that" is restrictive, whereas "which" in non-restrictive. In
> > > other words you mean the rest of the sentence after "which" to
> > > constrain the word "anything", i.e., to restrict what is covered.
> > > This distinction is important in technical writing; unfortunately
> > > even native speakers sometimes get it wrong.
> >
> > OK, that is subtle but noted!
> >
> > I'll hide behind my standard "I only started to learn English in 5th
> > grade" excuse. :-)
> You have no need of an excuse, because your original wording was correct,
> and is exactly how most British English users would put it.
>
> Rentsch is wrong to think that using 'that' means anything different.
> His claim comes straight out of Strunk & White's usage guide,
> which has been debunked by English grammar experts, such as Geoff Pullum.
>
> I personally prefer 'that' to 'which' in restrictive clauses,
> but that is a matter of aesthetics, not grammatical correctness.
> --
> Bill Findlay

Not being an expert of English English or of American English or of any other English variation...
In this particular case I'd use 'which' rather than 'that'. Because I don't like a look of the same word 'that' appearing twice just two words apart. In different meanings, which probably makes things worse.

There is another reason for me to often prefer 'which' over 'that' : it's o.k. to put comma before 'which', but comma before 'that' is considered bad grammar.
I like commas, but sometimes (it depends on context) dislike annoying readers with bad grammar.

On Friday, March 11, 2022 at 2:27:57 PM UTC+2, Michael S wrote:
> On Thursday, March 10, 2022 at 6:55:16 PM UTC+2, Bill Findlay wrote:
> > On 10 Mar 2022, Terje Mathisen wrote
> > (in article <t0ct7p$muk$1...@gioia.aioe.org>):
> > > Tim Rentsch wrote:
> > > > Terje Mathisen<terje.m...@tmsw.no> writes:
> > > > > The most fun is when I find ways to remove all internal branching
> > > > > related to exceptional data, i.e. anything which can impede that
> > > > > nicely flowing stream of water going downhill.
> > > >
> > > > In that sentence the word "which" should be "that". The reason is
> > > > "that" is restrictive, whereas "which" in non-restrictive. In
> > > > other words you mean the rest of the sentence after "which" to
> > > > constrain the word "anything", i.e., to restrict what is covered.
> > > > This distinction is important in technical writing; unfortunately
> > > > even native speakers sometimes get it wrong.
> > >
> > > OK, that is subtle but noted!
> > >
> > > I'll hide behind my standard "I only started to learn English in 5th
> > > grade" excuse. :-)
> > You have no need of an excuse, because your original wording was correct,
> > and is exactly how most British English users would put it.
> >
> > Rentsch is wrong to think that using 'that' means anything different.
> > His claim comes straight out of Strunk & White's usage guide,
> > which has been debunked by English grammar experts, such as Geoff Pullum.
> >
> > I personally prefer 'that' to 'which' in restrictive clauses,
> > but that is a matter of aesthetics, not grammatical correctness.
> > --
> > Bill Findlay
> Not being an expert of English English or of American English or of any other English variation...
> In this particular case I'd use 'which' rather than 'that'. Because I don't like a look of the same word 'that' appearing twice just two words apart. In different meanings, which probably makes things worse.

Thinking about it, not "probably". different meanings certainly make things worse.
Repeated (recurring?) 'that' in the same meaning, like that, is o.k with me:

This is the farmer sowing his corn,
That kept the cock that crow'd in the morn,
That waked the priest all shaven and shorn,
That married the man all tatter'd and torn,
That kissed the maiden all forlorn,
That milk'd the cow with the crumpled horn,
That tossed the dog,
That worried the cat,
That killed the rat,
That ate the malt
That lay in the house that Jack built.

>
> There is another reason for me to often prefer 'which' over 'that' : it's o.k. to put comma before 'which', but comma before 'that' is considered bad grammar.
> I like commas, but sometimes (it depends on context) dislike annoying readers with bad grammar.

On 11/03/2022 12:29, Terje Mathisen wrote:
> Tim Rentsch wrote:
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>
>>> Tim Rentsch wrote:
>>>
>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>
>>>>> Tim Rentsch wrote:
>>>>>
>>>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>>>
>>>>>>> Tim Rentsch wrote:
>>>>>>>
>>>>>>>> Ivan Godard <ivan@millcomputing.com> writes:
>>>>>>>>
>>>>>>>> [...]
>>>>>>>>
>>>>>>>>> I think the problem is really a linguistic one:  our programming
>>>>>>>>> languages have caused us to think about our programs in control
>>>>>>>>> flow terms, [...]
>>>>>>>>
>>>>>>>> Some of us.  Not everyone, fortunately.
>>>>>>>
>>>>>>> I tend to think much more in data flow terms, as I've written
>>>>>>> before:
>>>>>>>
>>>>>>> An optimal program is like a creek finding its path down from the
>>>>>>> mountain, always searching for the path of least resistance.
>>>>>>
>>>>>> It's an interesting simile.  Note by the way that creeks are
>>>>>> greedy algorithms, in the sense of being only locally optimal,
>>>>>> not necessarily globally optimal.
>>>>>>
>>>>>> To me the more interesting question is how does this perspective
>>>>>> affect how the code looks?  If reading your programs, would I see
>>>>>> something that looks pretty much like other imperative code, or
>>>>>> would there be some distinguishing characteristics that would
>>>>>> indicate your different thought mode?  Can you say anything about
>>>>>> what those characteristics might be?  Or perhaps give an example
>>>>>> or two?  (Short is better if that is feasible.)
>>>>>
>>>>> First example:  Use (very) small lookup tables to get rid of branches,
>>>>> typically trying to turn code state machines into data state
>>>>> machines.  This is driven by the fact that modern CPUs are much better
>>>>> at dependent loads than unpredictable branches.
>>>>>
>>>>> I typically try to write code that can run in SIMD mode, i.e. using
>>>>> tables/branchless/predicated ops to handle any single-lane alternate
>>>>> paths.
>>>>>
>>>>> Such code can also much more often scale across multiple cores/systems
>>>>> even if that means that I have to do some redundant work across the
>>>>> boundaries.  I.e. when I process lidar data I can make the problem
>>>>> almost embarrasingly parallelizable by splitting the input into tiles
>>>>> with 35-50m overlap:  This is sufficient to effectively eliminate all
>>>>> edge artifacts when I generate contours and vegetation
>>>>> classifications.
>>>>
>>>> Interesting.  Thank you for the examples.
>>>
>>> The core idea there is that it can often make sense to do extra work
>>> as long as that removes the cost of maintaining exact boundaries.  A
>>> similar idea was the building block for my julian day to Y-M-D
>>> conversion:
>>>
>>> The math to do so is quite complicated, so instead I make a very quick
>>> approximate guess and do the reverse (very fast!) calculation which
>>> ends with a branchless adjustment if the guess was off-by-one.
>>
>> I am intrigued.  Would you mind sharing the code (either posting
>> or sending to me via email, whichever you think more appropriate)?
>>
>>>>> The most fun is when I find ways to remove all internal branching
>>>>> related to exceptional data, i.e. anything which can impede that
>>>>> nicely flowing stream of water going downhill.
>>>>
>>>> In that sentence the word "which" should be "that".  The reason is
>>>> "that" is restrictive, whereas "which" in non-restrictive.  In
>>>> other words you mean the rest of the sentence after "which" to
>>>> constrain the word "anything", i.e., to restrict what is covered.
>>>> This distinction is important in technical writing;  unfortunately
>>>> even native speakers sometimes get it wrong.
>>>
>>> OK, that is subtle but noted!
>>>
>>> I'll hide behind my standard "I only started to learn English in 5th
>>> grade" excuse. :-)
>>
>> No excuse needed.  I routinely give such comments to people whose
>> first language is other than English, not with the intention of
>> faulting a bad usage but with the idea of helping them better
>> learn the subtleties and bear traps of English.  If anyone should
>> give an excuse, I should, because my own other-language skills are
>> so limited.  I admire anyone who speaks more than one language, as
>> I have found it very very difficult to do so.
>
> This is actually more interesting than I immediately thought:
>
> First, is there a difference between US and UK English here?
>
> Looking at it now, to me using "anything which can" vs "anything that
> can" does have those two different meanings: The first one is in fact
> more inclusive than the second, i.e. "which" also includes stuff that
> only incidentally or as a side effect cause this, while "that" implies
> that it is more of a primary result.
>
> This was actually what I was trying to express.
>
> Regards,
> Terje
>

The point of language is to communicate. Unless you can be absolutely
sure that the reader will distinguish between "which" and "that",
interpreting the difference exactly as you intended, then you cannot
communicate any semantic information by making the distinction. So if
you need to communicate this information to a wider audience, you have
to do it in a different way - expressing yourself in a different manner
or adding more text.

I am a native English speaker, well versed in technical writing, and
with an above-average interest in and knowledge of grammar. (AFAIK Tim
has far more experience in technical writing than me, however.) I would
not infer anything from the use of "which" or "that" in this context, I
would not assume any writer intended any implication, and I would not
assume any reader would infer anything from it.

Language changes over time, it varies from place to place (though I
don't think this particular case is an American versus British issue),
and it varies from context. Little-used and subtle implications do not
last.

Of course it is best to pick the most appropriate word at the time. But
that does not necessarily mean picking the word that has, in some
circles, particular under-tones. "Which" can well be considered a
better choice to avoid the duplication of the word "that" (as Michael
mentioned). Personally, I'd probably write "anything that can impede
the nicely flowing stream".

Oh, and I'd have a comma after "i.e." :-)

(Despite knowing full well that typesetting rules, like grammar, changes
over time, and that small details rarely matter, I still find myself
mentally nit-picking typographical errors. Perhaps it is because I read
"The TeXbook" many years ago.)

On Friday, March 11, 2022 at 2:53:36 PM UTC+2, David Brown wrote:
> On 11/03/2022 12:29, Terje Mathisen wrote:
> > Tim Rentsch wrote:
> >> Terje Mathisen <terje.m...@tmsw.no> writes:
> >>
> >>> Tim Rentsch wrote:
> >>>
> >>>> Terje Mathisen <terje.m...@tmsw.no> writes:
> >>>>
> >>>>> Tim Rentsch wrote:
> >>>>>
> >>>>>> Terje Mathisen <terje.m...@tmsw.no> writes:
> >>>>>>
> >>>>>>> Tim Rentsch wrote:
> >>>>>>>
> >>>>>>>> Ivan Godard <iv...@millcomputing.com> writes:
> >>>>>>>>
> >>>>>>>> [...]
> >>>>>>>>
> >>>>>>>>> I think the problem is really a linguistic one: our programming
> >>>>>>>>> languages have caused us to think about our programs in control
> >>>>>>>>> flow terms, [...]
> >>>>>>>>
> >>>>>>>> Some of us. Not everyone, fortunately.
> >>>>>>>
> >>>>>>> I tend to think much more in data flow terms, as I've written
> >>>>>>> before:
> >>>>>>>
> >>>>>>> An optimal program is like a creek finding its path down from the
> >>>>>>> mountain, always searching for the path of least resistance.
> >>>>>>
> >>>>>> It's an interesting simile. Note by the way that creeks are
> >>>>>> greedy algorithms, in the sense of being only locally optimal,
> >>>>>> not necessarily globally optimal.
> >>>>>>
> >>>>>> To me the more interesting question is how does this perspective
> >>>>>> affect how the code looks? If reading your programs, would I see
> >>>>>> something that looks pretty much like other imperative code, or
> >>>>>> would there be some distinguishing characteristics that would
> >>>>>> indicate your different thought mode? Can you say anything about
> >>>>>> what those characteristics might be? Or perhaps give an example
> >>>>>> or two? (Short is better if that is feasible.)
> >>>>>
> >>>>> First example: Use (very) small lookup tables to get rid of branches,
> >>>>> typically trying to turn code state machines into data state
> >>>>> machines. This is driven by the fact that modern CPUs are much better
> >>>>> at dependent loads than unpredictable branches.
> >>>>>
> >>>>> I typically try to write code that can run in SIMD mode, i.e. using
> >>>>> tables/branchless/predicated ops to handle any single-lane alternate
> >>>>> paths.
> >>>>>
> >>>>> Such code can also much more often scale across multiple cores/systems
> >>>>> even if that means that I have to do some redundant work across the
> >>>>> boundaries. I.e. when I process lidar data I can make the problem
> >>>>> almost embarrasingly parallelizable by splitting the input into tiles
> >>>>> with 35-50m overlap: This is sufficient to effectively eliminate all
> >>>>> edge artifacts when I generate contours and vegetation
> >>>>> classifications.
> >>>>
> >>>> Interesting. Thank you for the examples.
> >>>
> >>> The core idea there is that it can often make sense to do extra work
> >>> as long as that removes the cost of maintaining exact boundaries. A
> >>> similar idea was the building block for my julian day to Y-M-D
> >>> conversion:
> >>>
> >>> The math to do so is quite complicated, so instead I make a very quick
> >>> approximate guess and do the reverse (very fast!) calculation which
> >>> ends with a branchless adjustment if the guess was off-by-one.
> >>
> >> I am intrigued. Would you mind sharing the code (either posting
> >> or sending to me via email, whichever you think more appropriate)?
> >>
> >>>>> The most fun is when I find ways to remove all internal branching
> >>>>> related to exceptional data, i.e. anything which can impede that
> >>>>> nicely flowing stream of water going downhill.
> >>>>
> >>>> In that sentence the word "which" should be "that". The reason is
> >>>> "that" is restrictive, whereas "which" in non-restrictive. In
> >>>> other words you mean the rest of the sentence after "which" to
> >>>> constrain the word "anything", i.e., to restrict what is covered.
> >>>> This distinction is important in technical writing; unfortunately
> >>>> even native speakers sometimes get it wrong.
> >>>
> >>> OK, that is subtle but noted!
> >>>
> >>> I'll hide behind my standard "I only started to learn English in 5th
> >>> grade" excuse. :-)
> >>
> >> No excuse needed. I routinely give such comments to people whose
> >> first language is other than English, not with the intention of
> >> faulting a bad usage but with the idea of helping them better
> >> learn the subtleties and bear traps of English. If anyone should
> >> give an excuse, I should, because my own other-language skills are
> >> so limited. I admire anyone who speaks more than one language, as
> >> I have found it very very difficult to do so.
> >
> > This is actually more interesting than I immediately thought:
> >
> > First, is there a difference between US and UK English here?
> >
> > Looking at it now, to me using "anything which can" vs "anything that
> > can" does have those two different meanings: The first one is in fact
> > more inclusive than the second, i.e. "which" also includes stuff that
> > only incidentally or as a side effect cause this, while "that" implies
> > that it is more of a primary result.
> >
> > This was actually what I was trying to express.
> >
> > Regards,
> > Terje
> >
> The point of language is to communicate.

It depends.
For many, if not for most, posters on comp.arch, the main point is to express themselves.
Communication is secondary.

On 3/11/2022 4:53 AM, David Brown wrote:
> On 11/03/2022 12:29, Terje Mathisen wrote:
>> Tim Rentsch wrote:
>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>
>>>> Tim Rentsch wrote:
>>>>
>>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>>
>>>>>> Tim Rentsch wrote:
>>>>>>
>>>>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>>>>
>>>>>>>> Tim Rentsch wrote:
>>>>>>>>
>>>>>>>>> Ivan Godard <ivan@millcomputing.com> writes:
>>>>>>>>>
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>> I think the problem is really a linguistic one:  our programming
>>>>>>>>>> languages have caused us to think about our programs in control
>>>>>>>>>> flow terms, [...]
>>>>>>>>>
>>>>>>>>> Some of us.  Not everyone, fortunately.
>>>>>>>>
>>>>>>>> I tend to think much more in data flow terms, as I've written
>>>>>>>> before:
>>>>>>>>
>>>>>>>> An optimal program is like a creek finding its path down from the
>>>>>>>> mountain, always searching for the path of least resistance.
>>>>>>>
>>>>>>> It's an interesting simile.  Note by the way that creeks are
>>>>>>> greedy algorithms, in the sense of being only locally optimal,
>>>>>>> not necessarily globally optimal.
>>>>>>>
>>>>>>> To me the more interesting question is how does this perspective
>>>>>>> affect how the code looks?  If reading your programs, would I see
>>>>>>> something that looks pretty much like other imperative code, or
>>>>>>> would there be some distinguishing characteristics that would
>>>>>>> indicate your different thought mode?  Can you say anything about
>>>>>>> what those characteristics might be?  Or perhaps give an example
>>>>>>> or two?  (Short is better if that is feasible.)
>>>>>>
>>>>>> First example:  Use (very) small lookup tables to get rid of branches,
>>>>>> typically trying to turn code state machines into data state
>>>>>> machines.  This is driven by the fact that modern CPUs are much better
>>>>>> at dependent loads than unpredictable branches.
>>>>>>
>>>>>> I typically try to write code that can run in SIMD mode, i.e. using
>>>>>> tables/branchless/predicated ops to handle any single-lane alternate
>>>>>> paths.
>>>>>>
>>>>>> Such code can also much more often scale across multiple cores/systems
>>>>>> even if that means that I have to do some redundant work across the
>>>>>> boundaries.  I.e. when I process lidar data I can make the problem
>>>>>> almost embarrasingly parallelizable by splitting the input into tiles
>>>>>> with 35-50m overlap:  This is sufficient to effectively eliminate all
>>>>>> edge artifacts when I generate contours and vegetation
>>>>>> classifications.
>>>>>
>>>>> Interesting.  Thank you for the examples.
>>>>
>>>> The core idea there is that it can often make sense to do extra work
>>>> as long as that removes the cost of maintaining exact boundaries.  A
>>>> similar idea was the building block for my julian day to Y-M-D
>>>> conversion:
>>>>
>>>> The math to do so is quite complicated, so instead I make a very quick
>>>> approximate guess and do the reverse (very fast!) calculation which
>>>> ends with a branchless adjustment if the guess was off-by-one.
>>>
>>> I am intrigued.  Would you mind sharing the code (either posting
>>> or sending to me via email, whichever you think more appropriate)?
>>>
>>>>>> The most fun is when I find ways to remove all internal branching
>>>>>> related to exceptional data, i.e. anything which can impede that
>>>>>> nicely flowing stream of water going downhill.
>>>>>
>>>>> In that sentence the word "which" should be "that".  The reason is
>>>>> "that" is restrictive, whereas "which" in non-restrictive.  In
>>>>> other words you mean the rest of the sentence after "which" to
>>>>> constrain the word "anything", i.e., to restrict what is covered.
>>>>> This distinction is important in technical writing;  unfortunately
>>>>> even native speakers sometimes get it wrong.
>>>>
>>>> OK, that is subtle but noted!
>>>>
>>>> I'll hide behind my standard "I only started to learn English in 5th
>>>> grade" excuse. :-)
>>>
>>> No excuse needed.  I routinely give such comments to people whose
>>> first language is other than English, not with the intention of
>>> faulting a bad usage but with the idea of helping them better
>>> learn the subtleties and bear traps of English.  If anyone should
>>> give an excuse, I should, because my own other-language skills are
>>> so limited.  I admire anyone who speaks more than one language, as
>>> I have found it very very difficult to do so.
>>
>> This is actually more interesting than I immediately thought:
>>
>> First, is there a difference between US and UK English here?
>>
>> Looking at it now, to me using "anything which can" vs "anything that
>> can" does have those two different meanings: The first one is in fact
>> more inclusive than the second, i.e. "which" also includes stuff that
>> only incidentally or as a side effect cause this, while "that" implies
>> that it is more of a primary result.
>>
>> This was actually what I was trying to express.
>>
>> Regards,
>> Terje
>>
>
> The point of language is to communicate. Unless you can be absolutely
> sure that the reader will distinguish between "which" and "that",
> interpreting the difference exactly as you intended, then you cannot
> communicate any semantic information by making the distinction. So if
> you need to communicate this information to a wider audience, you have
> to do it in a different way - expressing yourself in a different manner
> or adding more text.
>
> I am a native English speaker, well versed in technical writing, and
> with an above-average interest in and knowledge of grammar. (AFAIK Tim
> has far more experience in technical writing than me, however.) I would
> not infer anything from the use of "which" or "that" in this context, I
> would not assume any writer intended any implication, and I would not
> assume any reader would infer anything from it.
>
> Language changes over time, it varies from place to place (though I
> don't think this particular case is an American versus British issue),
> and it varies from context. Little-used and subtle implications do not
> last.

Even long-standing language notion can die. I use both the conditional -
"if I were a rich man..." instead of "if I was a rich man...", and
distinguish "shall" from "will" - simple future instead of intentional.
Both the conditional and and use of shall have largely disappeared in my
lifetime.

But then, I've sometimes been told I have a somewhat antiquated style :-)

Bill Findlay <findlaybill@blueyonder.co.uk> writes:

> On 10 Mar 2022, Terje Mathisen wrote
> (in article <t0ct7p$muk$1@gioia.aioe.org>):
>
>> Tim Rentsch wrote:
>>
>>> Terje Mathisen<terje.mathisen@tmsw.no> writes:
>>>
>>>> The most fun is when I find ways to remove all internal branching
>>>> related to exceptional data, i.e. anything which can impede that
>>>> nicely flowing stream of water going downhill.
>>>
>>> In that sentence the word "which" should be "that". The reason is
>>> "that" is restrictive, whereas "which" in non-restrictive. In
>>> other words you mean the rest of the sentence after "which" to
>>> constrain the word "anything", i.e., to restrict what is covered.
>>> This distinction is important in technical writing; unfortunately
>>> even native speakers sometimes get it wrong.
>>
>> OK, that is subtle but noted!
>>
>> I'll hide behind my standard "I only started to learn English in 5th
>> grade" excuse. :-)
>
> You have no need of an excuse, because your original wording was
> correct, and is exactly how most British English users would put it.
>
> Rentsch is wrong to think that using 'that' means anything different.
> His claim comes straight out of Strunk & White's usage guide, which
> has been debunked by English grammar experts, such as Geoff Pullum.
>
> I personally prefer 'that' to 'which' in restrictive clauses,
> but that is a matter of aesthetics, not grammatical correctness.

Apparently Mr Findlay is offering himself as an authority on English
grammar.

I am not offering myself as an authority. I mean only to report
what I have heard and read elsewhere. If I remember correctly, I
first heard this rule from a tech writer where I was working many
years ago. Some years later I did read The Elements of Style,
although I don't have any specific memory of it mentioning this
distinction (but of course it almost certainly did). Other tech
writers I have talked to over the years have concurred on the
that/which distinction.

Consulting a handful of online dictionaries for "that", all agreed
on "that" clauses being restrictive or defining.

Consulting a handful of online dictionaries for "which", the results
were divided. Some clearly said that "which" is non-restrictive,
some didn't say, and at least one said "which" can be used in place
of "that".

It's possible that there is some correlation between the different
views and the question of American English and British English. I
did not investigate that question. (I speak and write American
English, although at times I may inadvertently employ some British
English phrasing without realizing it.)

A web search for "that vs which" (without the quotes) turned up a
lot of hits (I don't know how many). Looking at the first page of
results (I use duckduckgo as my search engine), all agreed on the
principle of using "that" for restrictive or defining clauses and
using "which" for non-restrictive clauses. I think the mildest
support was in a page on grammarbook.com; it said this:

NOTE: We feel that maintaining the distinction between that
and which in essential and nonessential phrases and clauses
is useful, even though the principle is sometimes disregarded
by experienced writers.

After seeing all this, I offer the following advice.

If you mean to introduce a restrictive or defining clause, always
use "that", because it's never wrong, and will never confuse a
reader about what is meant.

If you mean to introduce a non-restrictive clause, which gives
only additional information and does not otherwise affect the
noun or phrase being referenced, use "which". To emphasize the
non-restrictiveness, commas can be used before and after the
"which" clause. Using both "which" and delimiting commas is
also, AFAICT, never wrong, and the commas in particular should
remove any confusion about the intended meaning not being
restrictive.

If you want to allow some ambiguity or the possiblity of confusion
or misunderstanding, feel free to use "which" in place of "that"
in introducing a restrictive clause. In my own writing I usually
try to remove as much ambiguity, and also potential confusion or
misunderstanding, as I can. But different writers have different
preferences.

Final thought: I encourage anyone who is interested to consult
any dictionaries, style guides, essays on that vs which, and so
forth, that they can easily find, to get a broader sense of the
question.

Michael S <already5chosen@yahoo.com> writes:

> For many, if not for most, posters on comp.arch, the main point is
> to express themselves. Communication is secondary.

They want to express themselves but don't care if they are
communicating? A profound idea. Maybe that explains my
reactions to many postings.

Terje Mathisen <terje.mathisen@tmsw.no> writes:

> Tim Rentsch wrote:
>
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>
>>> Tim Rentsch wrote:
>>>
>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>
>>>>> The most fun is when I find ways to remove all internal
>>>>> branching related to exceptional data, i.e. anything which can
>>>>> impede that nicely flowing stream of water going downhill.
>>>>
>>>> In that sentence the word "which" should be "that". The reason
>>>> is "that" is restrictive, whereas "which" in non-restrictive.
>>>> In other words you mean the rest of the sentence after "which"
>>>> to constrain the word "anything", i.e., to restrict what is
>>>> covered. This distinction is important in technical writing;
>>>> unfortunately even native speakers sometimes get it wrong.
>>>
>>> OK, that is subtle but noted!
>>>
>>> I'll hide behind my standard "I only started to learn English in
>>> 5th grade" excuse. :-)
>>
>> No excuse needed. I routinely give such comments to people whose
>> first language is other than English, not with the intention of
>> faulting a bad usage but with the idea of helping them better
>> learn the subtleties and bear traps of English. If anyone should
>> give an excuse, I should, because my own other-language skills
>> are so limited. I admire anyone who speaks more than one
>> language, as I have found it very very difficult to do so.
>
> This is actually more interesting than I immediately thought:
>
> First, is there a difference between US and UK English here?

I suspect there is, but I don't have any direct evidence for that
conclusion.

More generally, I have just responded to Mr Findlay's comments,
and you may find my comments there to be of interest.

> Looking at it now, to me using "anything which can" vs "anything that
> can" does have those two different meanings: The first one is in fact
> more inclusive than the second, i.e. "which" also includes stuff that
> only incidentally or as a side effect cause this, while "that" implies
> that it is more of a primary result.

To me the key word is "anything". You don't mean literally anything,
but "anything subject to the limitations of the following clause" (at
least, that's what I think you mean). So I'm not sure what difference
you are trying to explain here.

> This was actually what I was trying to express.

Which one, the first or the second? (And I'm still not sure what you
think the difference is between them.)

On 11 Mar 2022, Tim Rentsch wrote
(in article <86h784b9ki.fsf@linuxsc.com>):

> Bill Findlay<findlaybill@blueyonder.co.uk> writes:
>
> > On 10 Mar 2022, Terje Mathisen wrote
> > (in article <t0ct7p$muk$1@gioia.aioe.org>):
> >
> > > Tim Rentsch wrote:
> > >
> > > > Terje Mathisen<terje.mathisen@tmsw.no> writes:
> > > >
> > > > > The most fun is when I find ways to remove all internal branching
> > > > > related to exceptional data, i.e. anything which can impede that
> > > > > nicely flowing stream of water going downhill.
> > > >
> > > > In that sentence the word "which" should be "that". The reason is
> > > > "that" is restrictive, whereas "which" in non-restrictive. In
> > > > other words you mean the rest of the sentence after "which" to
> > > > constrain the word "anything", i.e., to restrict what is covered.
> > > > This distinction is important in technical writing; unfortunately
> > > > even native speakers sometimes get it wrong.
> > >
> > > OK, that is subtle but noted!
> > >
> > > I'll hide behind my standard "I only started to learn English in 5th
> > > grade" excuse. :-)
> >
> > You have no need of an excuse, because your original wording was
> > correct, and is exactly how most British English users would put it.
> >
> > Rentsch is wrong to think that using 'that' means anything different.
> > His claim comes straight out of Strunk & White's usage guide, which
> > has been debunked by English grammar experts, such as Geoff Pullum.
> >
> > I personally prefer 'that' to 'which' in restrictive clauses,
> > but that is a matter of aesthetics, not grammatical correctness.
>
> Apparently Mr Findlay is offering himself as an authority on English
> grammar.

To the contrary, I defer to the expertise of Professor Geoff Pullum,
one of the authors of the "The Cambridge Grammar of the English Language".
See, for example:<https://languagelog.ldc.upenn.edu/nll/?p=4357>

> I am not offering myself as an authority.

!

--
Bill Findlay

To Tim and everyone else who contributed to this exchange on language,
Thank you!

I did learn something, what I'm most happy about is that I seem to be
getting sufficiently fluid that I subconsciously choose exactly how to
express myself, without thinking about all the details. :-)

Terje
PS. Just getting rid of Covid here, something like 20% of the Norwegian
population seems to be going through it more or less at the same time,
thankfully with very little serious consequences. It seems like we are
getting out of these two years (I sent everyone home from the office in
Oslo exactly two years ago today) with something like 25-30% reduction
in death rate because all the covid restrictions have removed two full
flu seasons.

Tim Rentsch wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>
>> Tim Rentsch wrote:
>>
>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>
>>>> Tim Rentsch wrote:
>>>>
>>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>>
>>>>>> The most fun is when I find ways to remove all internal
>>>>>> branching related to exceptional data, i.e. anything which can
>>>>>> impede that nicely flowing stream of water going downhill.
>>>>>
>>>>> In that sentence the word "which" should be "that". The reason
>>>>> is "that" is restrictive, whereas "which" in non-restrictive.
>>>>> In other words you mean the rest of the sentence after "which"
>>>>> to constrain the word "anything", i.e., to restrict what is
>>>>> covered. This distinction is important in technical writing;
>>>>> unfortunately even native speakers sometimes get it wrong.
>>>>
>>>> OK, that is subtle but noted!
>>>>
>>>> I'll hide behind my standard "I only started to learn English in
>>>> 5th grade" excuse. :-)
>>>
>>> No excuse needed. I routinely give such comments to people whose
>>> first language is other than English, not with the intention of
>>> faulting a bad usage but with the idea of helping them better
>>> learn the subtleties and bear traps of English. If anyone should
>>> give an excuse, I should, because my own other-language skills
>>> are so limited. I admire anyone who speaks more than one
>>> language, as I have found it very very difficult to do so.
>>
>> This is actually more interesting than I immediately thought:
>>
>> First, is there a difference between US and UK English here?
>
> I suspect there is, but I don't have any direct evidence for that
> conclusion.
>
> More generally, I have just responded to Mr Findlay's comments,
> and you may find my comments there to be of interest.
>
>> Looking at it now, to me using "anything which can" vs "anything that
>> can" does have those two different meanings: The first one is in fact
>> more inclusive than the second, i.e. "which" also includes stuff that
>> only incidentally or as a side effect cause this, while "that" implies
>> that it is more of a primary result.
>
> To me the key word is "anything". You don't mean literally anything,
> but "anything subject to the limitations of the following clause" (at
> least, that's what I think you mean). So I'm not sure what difference
> you are trying to explain here.
>
>> This was actually what I was trying to express.
>
> Which one, the first or the second? (And I'm still not sure what you
> think the difference is between them.)
>

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

George Neuner wrote:
> On Wed, 9 Mar 2022 11:36:53 -0000 (UTC), Thomas Koenig
> <tkoenig@netcologne.de> wrote:
>
>> If you want, you can have a softcore for your CPU and define special
>> instructions for your special needs. I don't think it is easy
>> to modify the FPGA programming on the fly.
>
> With the right architecture, it can be relatively easy.
>
> First, small to medium sized FPGA can be reconfigured very rapidly:
> for many parts that are likely to used as 'accelerator' co-processors
> it takes less than a millisecond for a full reconfiguration.
>
> Second, most FPGAs large enough to support soft cores now support
> partial reconfiguration while running. Essentially you can load a
> single 'full' binary or some (model dependent) number of 'slice'
> binaries which allow you to reprogram one area of the chip while other
> areas continue to execute. The details obviously are model specific,
> and, of course, the external hardware must be able to drive the chip
> for slice programming if that is desired.
>
>
>
> In the late 90s I worked on software support for a prototype FPGA
> based array processor. It was conceived originally as an image
> processing accelerator, but the implementation ended up general enough
> to be used as a 'compute server' suitable for more general array
> processing.
>
> The board had 133MHz PCI bus interface, from 1 to 4 'compute element'
> FPGAs, a programmable interconnect that enabled using the FPGAs
> individually or in any combination, a high-speed banked DRAM having
> 2-dimensional (rectangular block) addressing ability that was able to
> support 32-bit 2R/1W access simultaneously from all FPGAs at full
> speed, and a DSP that provided board control, execution of user
> scripts (described below), and general FP support.
> [Larger FPGAs of that era could implement simple FP functions and even
> some compositions of simple functions, but complex FP pretty much was
> out of the question - so the DSP was necessary. The board was
> designed with the FPGAs as plug-in modules to accomodate expansion and
> (to a point) switching to larger FPGAs as they became affordable.]
>
> Rather than allow arbitrary user FPGA programs, we implemented a
> library of FPGA based array processing functions and a scripting
> language to use them. The compiler/runtime directed allocations in
> various memories: DRAM, FPGA parameter and scratch SRAMS, etc., and
> handled the complicated work of setting up function parameter blocks,
> kicking the FPGAs to configure and execute, extracting results, and
> cleaning up afterward. The compiler supported chaining execution of
> multiple FPGA functions - as opposed to returning control to the
> script after every function - and automatically forwarded result to
> satisfy data dependencies between parameter blocks within the chain.
>
> Each parameter block included two identifiers that indicated which
> configuration binary to use and which function in that binary to
> execute. Kicking the FPGA to execute caused a hardware monitor
> (itself a tiny FPGA) to look at those identifiers and reconfigure the
> compute FPGA if the binary identifier didn't match. Each FPGA had a
> configuration cache holding (model dependent) 10 or more binaries. A
> typical binary implemented ~10..15 functions and could be loaded from
> the cache in less than 2ms.
> [At that time there was no partial reconfiguration, and for a part
> having 600..800 CLBs, full reconfiguration in under 2ms was quite
> fast.]
>
> A service on the host cooperated with the board runtime to partition
> the available FPGA resources (if desired), download user scripts and
> configuration binaries, and implemented a bi-directional messaging
> service to allow host programs to interact with running scripts. With
> multiple FPGAs installed on the board, multiple scripts could be run
> simultaneously [hence the 'compute server' aspect].
>
>
> The company had a number of industrial QA/QC products and was looking
> to improve on performance versus affordable SIMD processors. As a
> proof of concept we implemented an expensive image inspection normally
> performed using optimized SSE2 on a 1GHZ Pentium-4. Excluding image
> capture, the image processing on the Pentium took ~600ms. Our
> prototype board - using a single Xilinx Virtex-100 - performed the
> same processing in just ~20ms including 2 reconfigurations.
>
> Unfortunately, it never turned into a commercial product ... CPU
> speeds were rapidly improving and it was thought that the proprietary
> accelerator - even if it could be sold as a separate product - would
> not remain cost effective for long. But for a couple of years it was
> fun to work on (and with).

We discussed several of these approaches at the time, here on c.arch,
every single time the main problem was effectively Moore's Law: Each
time somebody had developed another FPGA accelerator board for function
X, I (or anyone else like me) could take the same algorithm, more or
less, turn it into hand-optimized x86 asm, and either immediately or
within two years, that SW would be just as fast as the FPGA and far cheaper.

Programming-wise it sounds sort of similar to the Cell Broadband Engine
of the Playstation: Could deliver excellent results but required
hardcore programming support from a quite small pool of
available/competent programmers.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"