On 11/03/2022 19:37, Ivan Godard wrote:
> On 3/11/2022 4:53 AM, David Brown wrote:
>>
>> 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.
>

In Norwegian, "jeg skal" (the same root as "I shall") is the future
tense - "I shall" or "I am going to". "Jeg vil" (the same root as "I
will") is "I want" or "I want to".

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

I think the change to language is inevitable - but I don't always think
it makes the language better. I agree with your usage in these
examples, and follow them too. However, you have to be careful in
expecting others to understand the distinction you make.

There was a time when you could separate "educated" people from
"uneducated" people. The educated class had spent long hours in the
classroom studying grammar and language, and Latin (several of the rules
of English grammar were imported directly from Latin in perhaps the 18th
or 19th centuries). A lot of technical or scientific writing was only
ever of interest within this group, and you could rely on a higher
minimum level of language.

Now, I would say, we have a more level field. People mix across a wider
range of backgrounds. There is more communication (and movement)
between countries, with people living and working in their second or
third language. In most aspects, this is a good thing IMHO. But it
does mean that some of the subtler aspects of language are lost.

On 11/03/2022 13:38, Michael S wrote:
> On Friday, March 11, 2022 at 2:27:57 PM UTC+2, Michael S wrote:
>> 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:
>
Here's a grammar challenge for you regarding repeated words - can you
punctuate the following?

Peter where John had had had had had had had had had had had the
examiners approval

(Hint - it's not just one sentence.)

On 3/12/2022 4:09 AM, Terje Mathisen wrote:
> 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.
>>

snip

>> 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.

Agreed. However, with the current situation of CPU not getting (much)
faster, and, of course larger capacity FPGAs, I wonder if that is still
true. Or does using graphics chips for this provide similar functionality

> 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.

Yes. But perhaps it could be that this pool of programmers provides a
"library" of low level primitives, that mere mortals can use fazirly easily.

I don't know if any of this is real - just wondering.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 3/12/2022 6:02 AM, Terje Mathisen wrote:
> 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.
>

Where I am living, even asking people to wear masks in public is
apparently asking too much, so most have not been bothering. It is a
little awkward when one is part of the minority who does actually bother
with this...

....

Well, there is this, and also the annoyance of being surrounded by YECs
(Young Earth Creationists), but not actually believing in this (most
evidence is against it; even linguistic and historical evidence is
against it; like some sort of bizarre consequence of word choice in the
KJV or something...).

Or, like the awkwardness of being generally leaning towards being
theistic, but not wanting to take a strong stance on anything outside
what can be observed and measured, but kinda leaning against
interpretations built strongly on supernatural events (say, we assume
people wrote what they believed happened, but stories can be
embellished, and events misinterpreted).

The question of religious identity becomes a bit fuzzy though when one
allows for a "well, it is what the people who wrote it believed
happened" stance, rather than a "it actually happened this way, and the
various creeds/etc are describing actual events". Will not say it didn't
happen though, as I don't take a "supernatural events don't happen"
stance either.

Not much evidence to support the notion that direct supernatural
intervention into normal peoples' lives is really a thing though, seems
like more of a "rare thing for special or historically significant
events" thing. A lot of what people may experience (as supernatural
events) may be more likely due to psychological or neurological
explanations or similar (just because one may experience something
doesn't mean it is real).

Though, the standard for evidence is particularly low in these circles
(and then there are a lot of people who take the "I believe it so that
makes it real" interpretation), ...

....

> 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.)
>>
>
>

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
> However, with the current situation of CPU not getting (much)
>faster, and, of course larger capacity FPGAs, I wonder if that is still
>true.

What is still true is that softcores are still a factor of 10 (typical
numbers I remember are 250MHz for fast-clocked softcores) slower than
custom-designed silicon CPUs, and I guess the same is true for other
logic functions implemented in FPGAs. So the niche for FPGA stuff
seems quite small to me: Functions that are not implemented in custom
silicon, take many steps in software, yet can be implemented with few
steps in hardware (and FPGAs); i.e., something like new crypto
algorithms that have not found their way into hardware accelerators
yet.

At least as far as performance is relevant; a larger niche for FPGAs
is helper chips for boards that do not have enough volume for
full-custom chips.

At least that's how the situation looks to me.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On 3/11/2022 12:37 PM, Ivan Godard wrote:
> 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 :-)
>
>

On 3/12/2022 11:25 AM, Anton Ertl wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>> However, with the current situation of CPU not getting (much)
>> faster, and, of course larger capacity FPGAs, I wonder if that is still
>> true.
>
> What is still true is that softcores are still a factor of 10 (typical
> numbers I remember are 250MHz for fast-clocked softcores) slower than
> custom-designed silicon CPUs, and I guess the same is true for other
> logic functions implemented in FPGAs. So the niche for FPGA stuff
> seems quite small to me: Functions that are not implemented in custom
> silicon, take many steps in software, yet can be implemented with few
> steps in hardware (and FPGAs); i.e., something like new crypto
> algorithms that have not found their way into hardware accelerators
> yet.
>

Also, 250 MHz would require either a high end FPGA or a very small core
(probably 16-bit).

It seems likely though, that a hybrid could be made, where FPGA logic
was glued on at the level of customizable CPU instructions, without the
CPU itself being implemented via the FPGA. In effect treating it like a
user-customizable coprocessor.

If this were limited to small enough "granules", it is possible the FPGA
logic could be run at or near the CPU's native clock speed, or with some
downsampling (Say, 4x or 8x). So, while each instruction represented via
FPGA logic is significantly slower than had it been native silicon, but
faster than had it been expressed with a series of normal CPU instructions.

> At least as far as performance is relevant; a larger niche for FPGAs
> is helper chips for boards that do not have enough volume for
> full-custom chips.
>
> At least that's how the situation looks to me.
>

Could be.

At present, they seem to come in one of several form factors:
Standalone boards, programmable via USB or similar, various connectors
(commonly "PMOD");
Boards that go inside a PC, typically via PCI-e, with little or no
external connectivity (and typically very expensive);
Boards that go inside a PC in an M.2 slot or similar.

The latter seem more relevant for "accelerators", whereas the former is
more relevant for those of us wanting to experiment with making custom
CPU SOC's, or for embedded control applications.

While an FPGA is more expensive than a normal microcontroller, it can do
some things a microcontroller can't (eg, saw something recently where
someone has used an FPGA to implement a custom digital oscilloscope +
logic analyzer).

....

On Saturday, March 12, 2022 at 11:38:27 AM UTC-6, Anton Ertl wrote:
> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> > However, with the current situation of CPU not getting (much)
> >faster, and, of course larger capacity FPGAs, I wonder if that is still
> >true.
> What is still true is that softcores are still a factor of 10 (typical
> numbers I remember are 250MHz for fast-clocked softcores) slower than
> custom-designed silicon CPUs, and I guess the same is true for other
> logic functions implemented in FPGAs. So the niche for FPGA stuff
> seems quite small to me: Functions that are not implemented in custom
> silicon, take many steps in software, yet can be implemented with few
> steps in hardware (and FPGAs); i.e., something like new crypto
> algorithms that have not found their way into hardware accelerators
> yet.
>
> At least as far as performance is relevant; a larger niche for FPGAs
> is helper chips for boards that do not have enough volume for
> full-custom chips.
>
> At least that's how the situation looks to me.
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

If power consumption is the metric, FPGAs have several advantages:

1) Power consumption is proportional to computation as unused FPGA fabric has low power consumption. FPGAs are designed to have low static power?
2) FPGAs tend to require less memory traffic. Memory data flow is more efficient, e.g. fewer loads and stores required. And memories are scaled in size to their usage.
3) Much computation is done outside of hard or soft cores and requires no instruction pipeline. In many cases a simple state machine suffices.
4) Moore's law still applies to FPGAs. E.g., they continue to get faster and more power efficient.
5) Single chip hybrid hard core(s) + FPGA fabric are readily available in many different combinations.
6) There is little internal fragmentation. Data sizes (and FPGA resources) are set to data requirements, not the register size.

On Saturday, March 12, 2022 at 4:43:01 PM UTC+2, David Brown wrote:
> On 11/03/2022 13:38, Michael S wrote:
> > On Friday, March 11, 2022 at 2:27:57 PM UTC+2, Michael S wrote:
> >> 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:
> >
> Here's a grammar challenge for you regarding repeated words - can you
> punctuate the following?
>
> Peter where John had had had had had had had had had had had the
> examiners approval
>
>
> (Hint - it's not just one sentence.)

I am not going to try.
The correct use or even adequate understanding of simple "had had" is already above my English language skills; "had had had" - more so.

On Saturday, March 12, 2022 at 7:38:27 PM UTC+2, Anton Ertl wrote:
> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> > However, with the current situation of CPU not getting (much)
> >faster, and, of course larger capacity FPGAs, I wonder if that is still
> >true.
> What is still true is that softcores are still a factor of 10 (typical
> numbers I remember are 250MHz for fast-clocked softcores) slower than
> custom-designed silicon CPUs,

You can push Nios2f to 300MHz on industrial-grade Startix-10 FPGA.
Probably, 10% faster on top commercial grade Stratix-10 FPGA, esp. smaller models.
But that will only work with your core running from either relativly small tightly-coupled memories (something like 128KB for both code and data)
or from even smaller instruction and data caches.
Also, don't forget, that apart from 10x slowdown factor in frequency, relatively to best "hard" CPUs there is at least 4x slowdown in IPC. May be, more than that, I didn't measure. Besides, an exact factor strongly depends on the application. May be, the simplest methodology that would not be totally misleading is to consider Nios2f IPC to be 80% of Arm Cortex A35.

> and I guess the same is true for other
> logic functions implemented in FPGAs.

Not necessarily. I can think about many functions that can be usefully run (on the same industrial-grade Startix-10) at above 400MHz.
A simpler ones at 450 MHz.

> So the niche for FPGA stuff
> seems quite small to me: Functions that are not implemented in custom
> silicon, take many steps in software, yet can be implemented with few
> steps in hardware (and FPGAs); i.e., something like new crypto
> algorithms that have not found their way into hardware accelerators
> yet.
>
> At least as far as performance is relevant; a larger niche for FPGAs
> is helper chips for boards that do not have enough volume for
> full-custom chips.
>
> At least that's how the situation looks to me.
>

That's sound about right.
FPGAs are *extremely* useful embedded devices that make majority of today's "long tail"
embedded computing industry at all possible. But FPGA-based "general-purpose" compute accelerators
are 99.9% hype and 0.1% substance. That's being generous.

> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On Saturday, March 12, 2022 at 9:12:24 PM UTC+2, JimBrakefield wrote:
> On Saturday, March 12, 2022 at 11:38:27 AM UTC-6, Anton Ertl wrote:
> > Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> > > However, with the current situation of CPU not getting (much)
> > >faster, and, of course larger capacity FPGAs, I wonder if that is still
> > >true.
> > What is still true is that softcores are still a factor of 10 (typical
> > numbers I remember are 250MHz for fast-clocked softcores) slower than
> > custom-designed silicon CPUs, and I guess the same is true for other
> > logic functions implemented in FPGAs. So the niche for FPGA stuff
> > seems quite small to me: Functions that are not implemented in custom
> > silicon, take many steps in software, yet can be implemented with few
> > steps in hardware (and FPGAs); i.e., something like new crypto
> > algorithms that have not found their way into hardware accelerators
> > yet.
> >
> > At least as far as performance is relevant; a larger niche for FPGAs
> > is helper chips for boards that do not have enough volume for
> > full-custom chips.
> >
> > At least that's how the situation looks to me.
> >
> > - anton
> > --
> > 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> > Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
> If power consumption is the metric, FPGAs have several advantages:
>
> 1) Power consumption is proportional to computation as unused FPGA fabric has low power consumption. FPGAs are designed to have low static power?

It depends on what you consider low.
Certainly, no FPGA is going to consume 1mW when idle.
Big FPGA is not going to consume 100mW either. But 1-2 Wats are possible, except in certain unfortunate families, like Arria-2, luckily not likely to be used for new projects.

> 2) FPGAs tend to require less memory traffic. Memory data flow is more efficient, e.g. fewer loads and stores required. And memories are scaled in size to their usage.
> 3) Much computation is done outside of hard or soft cores and requires no instruction pipeline. In many cases a simple state machine suffices.
> 4) Moore's law still applies to FPGAs. E.g., they continue to get faster and more power efficient.

More efficient - yes.
Bigger - yes. But the biggest FPGA offerings are already MCM (tiles) under the hood.
Faster - I am not sure. Quite possibly we will not see anything faster than Stratix-10 (available for ~4 years) for quite some time.
I mean, from the Big 2. I don't follow Achronix and similar exotic players.

> 5) Single chip hybrid hard core(s) + FPGA fabric are readily available in many different combinations.
> 6) There is little internal fragmentation. Data sizes (and FPGA resources) are set to data requirements, not the register size.

On Saturday, March 12, 2022 at 11:38:27 AM UTC-6, Anton Ertl wrote:
> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> > However, with the current situation of CPU not getting (much)
> >faster, and, of course larger capacity FPGAs, I wonder if that is still
> >true.
<
> What is still true is that softcores are still a factor of 10 (typical
> numbers I remember are 250MHz for fast-clocked softcores) slower than
> custom-designed silicon CPUs, and I guess the same is true for other
> logic functions implemented in FPGAs. So the niche for FPGA stuff
> seems quite small to me: Functions that are not implemented in custom
> silicon, take many steps in software, yet can be implemented with few
> steps in hardware (and FPGAs); i.e., something like new crypto
> algorithms that have not found their way into hardware accelerators
> yet.
<
A couple of points:
a) Anything programmable is going to be no faster than DIV-5 and more likely
to be DIV-20 (CPUs are 5GHz, FPGA is 250 MHz).
b) You are not going to get "your function unit" inside of a CPU, you are going
to have to put it outside of the CPU and likely outside of the L2 cache.
<
This has the consequences:
1) that if you are going to have such a function unit, and it is going to perform,
then you are going to have to feed it 1,000 units of work at a minimum;
2) you will need to give it more than 1 microseconds to do its job.
<
A difficult programming model for the synchronous vonNeumann paradigm.
<
>
> At least as far as performance is relevant; a larger niche for FPGAs
> is helper chips for boards that do not have enough volume for
> full-custom chips.
>
> At least that's how the situation looks to me.
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On 3/12/2022 2:10 PM, MitchAlsup wrote:
> On Saturday, March 12, 2022 at 11:38:27 AM UTC-6, Anton Ertl wrote:
>> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
>>> However, with the current situation of CPU not getting (much)
>>> faster, and, of course larger capacity FPGAs, I wonder if that is still
>>> true.
> <
>> What is still true is that softcores are still a factor of 10 (typical
>> numbers I remember are 250MHz for fast-clocked softcores) slower than
>> custom-designed silicon CPUs, and I guess the same is true for other
>> logic functions implemented in FPGAs. So the niche for FPGA stuff
>> seems quite small to me: Functions that are not implemented in custom
>> silicon, take many steps in software, yet can be implemented with few
>> steps in hardware (and FPGAs); i.e., something like new crypto
>> algorithms that have not found their way into hardware accelerators
>> yet.
> <
> A couple of points:
> a) Anything programmable is going to be no faster than DIV-5 and more likely
> to be DIV-20 (CPUs are 5GHz, FPGA is 250 MHz).
> b) You are not going to get "your function unit" inside of a CPU, you are going
> to have to put it outside of the CPU and likely outside of the L2 cache.
> <
> This has the consequences:
> 1) that if you are going to have such a function unit, and it is going to perform,
> then you are going to have to feed it 1,000 units of work at a minimum;
> 2) you will need to give it more than 1 microseconds to do its job.
> <
> A difficult programming model for the synchronous vonNeumann paradigm.

Rather than memorialize MSG, why not supply hardware continuations
(which need much the same stuff I expect) instead?

On Saturday, March 12, 2022 at 5:47:18 PM UTC-6, Ivan Godard wrote:
> On 3/12/2022 2:10 PM, MitchAlsup wrote:
> > On Saturday, March 12, 2022 at 11:38:27 AM UTC-6, Anton Ertl wrote:
> >> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> >>> However, with the current situation of CPU not getting (much)
> >>> faster, and, of course larger capacity FPGAs, I wonder if that is still
> >>> true.
> > <
> >> What is still true is that softcores are still a factor of 10 (typical
> >> numbers I remember are 250MHz for fast-clocked softcores) slower than
> >> custom-designed silicon CPUs, and I guess the same is true for other
> >> logic functions implemented in FPGAs. So the niche for FPGA stuff
> >> seems quite small to me: Functions that are not implemented in custom
> >> silicon, take many steps in software, yet can be implemented with few
> >> steps in hardware (and FPGAs); i.e., something like new crypto
> >> algorithms that have not found their way into hardware accelerators
> >> yet.
> > <
> > A couple of points:
> > a) Anything programmable is going to be no faster than DIV-5 and more likely
> > to be DIV-20 (CPUs are 5GHz, FPGA is 250 MHz).
> > b) You are not going to get "your function unit" inside of a CPU, you are going
> > to have to put it outside of the CPU and likely outside of the L2 cache..
> > <
> > This has the consequences:
> > 1) that if you are going to have such a function unit, and it is going to perform,
> > then you are going to have to feed it 1,000 units of work at a minimum;
> > 2) you will need to give it more than 1 microseconds to do its job.
> > <
> > A difficult programming model for the synchronous vonNeumann paradigm.
<
> Rather than memorialize MSG, why not supply hardware continuations
> (which need much the same stuff I expect) instead?
<
I did not realize I was memorializing MSG.
I don't see how you got that from what I wrote.
<
But assume I was in some remote sense::
<
In essence MSG passes ½ cache lines to target (the arguments)
Continuations pass 4 cache lines to target (an entire register set)
<
MSG recipient uses 80% of his own registers (4 arguments + 16 his).
Continuation recipient uses few of his own registers.
<
So, I don't see how the choices are remotely similar unless you are looking from
far enough away that you can't see the overhead from <ahem> the overhead.
<
The point I was making is that you are not going to get a function unit of your
design close enough to the CPU of their design to make use of it 1 command
at a time interface philosophy (co-processor.) It is more array-processor-like,
or GPU-like, than a function unit embedded in a CPU.

On Saturday, March 12, 2022 at 2:07:10 PM UTC-6, Michael S wrote:
> On Saturday, March 12, 2022 at 9:12:24 PM UTC+2, JimBrakefield wrote:
> > On Saturday, March 12, 2022 at 11:38:27 AM UTC-6, Anton Ertl wrote:
> > > Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> > > > However, with the current situation of CPU not getting (much)
> > > >faster, and, of course larger capacity FPGAs, I wonder if that is still
> > > >true.
> > > What is still true is that softcores are still a factor of 10 (typical
> > > numbers I remember are 250MHz for fast-clocked softcores) slower than
> > > custom-designed silicon CPUs, and I guess the same is true for other
> > > logic functions implemented in FPGAs. So the niche for FPGA stuff
> > > seems quite small to me: Functions that are not implemented in custom
> > > silicon, take many steps in software, yet can be implemented with few
> > > steps in hardware (and FPGAs); i.e., something like new crypto
> > > algorithms that have not found their way into hardware accelerators
> > > yet.
> > >
> > > At least as far as performance is relevant; a larger niche for FPGAs
> > > is helper chips for boards that do not have enough volume for
> > > full-custom chips.
> > >
> > > At least that's how the situation looks to me.
> > >
> > > - anton
> > > --
> > > 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> > > Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
> > If power consumption is the metric, FPGAs have several advantages:
> >
> > 1) Power consumption is proportional to computation as unused FPGA fabric has low power consumption. FPGAs are designed to have low static power?
> It depends on what you consider low.
> Certainly, no FPGA is going to consume 1mW when idle.
> Big FPGA is not going to consume 100mW either. But 1-2 Wats are possible, except in certain unfortunate families, like Arria-2, luckily not likely to be used for new projects.
> > 2) FPGAs tend to require less memory traffic. Memory data flow is more efficient, e.g. fewer loads and stores required. And memories are scaled in size to their usage.
> > 3) Much computation is done outside of hard or soft cores and requires no instruction pipeline. In many cases a simple state machine suffices.
> > 4) Moore's law still applies to FPGAs. E.g., they continue to get faster and more power efficient.
> More efficient - yes.
> Bigger - yes. But the biggest FPGA offerings are already MCM (tiles) under the hood.
> Faster - I am not sure. Quite possibly we will not see anything faster than Stratix-10 (available for ~4 years) for quite some time.
> I mean, from the Big 2. I don't follow Achronix and similar exotic players.
> > 5) Single chip hybrid hard core(s) + FPGA fabric are readily available in many different combinations.
> > 6) There is little internal fragmentation. Data sizes (and FPGA resources) are set to data requirements, not the register size.

|> Quite possibly we will not see anything faster than Stratix-10 (available for ~4 years) for quite some time.
I'm showing Stratix-10 at the "IA" 14nm node and Versal at the "AX" 7nm node. Going to smaller process nodes should reduce wire delay if nothing else. Further process nodes will take place slowly?
|>Big FPGA is not going to consume 100mW either.
Agreed, compared to 10 watts of an idle x86-64 however?
Of course if the ASIC is ten times faster, guess the power contest is ~tied.

On Thursday, March 10, 2022 at 9:55:16 AM UTC-7, Bill Findlay wrote:

> 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.

I certainly was unaware of any difference between "that" and "which"
in terms of being restrictive. I was not aware that this myth even existed.
Of course, if it existed in _Fowler_ and not just _Strunk & White_, then I
might have to reconsider my position.

John Savard

On Friday, March 11, 2022 at 4:30:02 AM UTC-7, Terje Mathisen wrote:

> 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 determine whether Strunk & White have _anything_ to back them up,
we need to ask some basic questions. What is "which", and what is "that"?

Which is the neuter counterpart of who.

A person who can read English. A computer which comes with a FORTRAN
compiler.

But we also say:

Who saw what happened? What computers are still available?

So in some cases, the neuter counterpart of who is _what_ instead of which.

But you don't use "what" where you would use "which", except if one's command
of grammar is weak:

My grandpappy had a rifle whut could shoot the paint off'n a barn door.

The most familiar use of "that" is as a pronoun, similar to "this" - _or_ as an article.

I was looking for this. Will that arrive on time?
I was looking for this book. Will that parcel arrive on time?

One can use that instead of "who" or "which":

A person that can read English. A computer that comes with a FORTRAN compiler.

A computer either comes with a FORTRAN compiler, or it doesn't. A person is either
able to read English or not.

So it's very difficult for me to see how "A computer that comes with a FORTRAN compiler"
and "A computer which comes with a FORTRAN compiler" can fail to describe the same
set of objects. In both cases, only computers can be members of the set, and only computers
in possession of a FORTRAN compiler.

John Savard

On Friday, March 11, 2022 at 11:37:25 AM UTC-7, Ivan Godard wrote:

> 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.

Of course, "Were I a rich man..." is the subjunctive.

And of course "If I were a rich man..." got a new lease on life from Fiddler
on the Roof.

John Savard

On Saturday, March 12, 2022 at 8:42:50 PM UTC-7, Quadibloc wrote:
> On Thursday, March 10, 2022 at 9:55:16 AM UTC-7, Bill Findlay wrote:

> > 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.

> I certainly was unaware of any difference between "that" and "which"
> in terms of being restrictive. I was not aware that this myth even existed.
> Of course, if it existed in _Fowler_ and not just _Strunk & White_, then I
> might have to reconsider my position.

Having looked in Fowler, I see that there _is_ a difference between "that" and
"which", and this actual difference may be the source of the confusion in
Strunk & White.

It is preferable to use "which" instead of "that" in a sentence such as the
following:

I always buy the genuine IBM PC, which comes with a shorter version of
the advanced BASIC interpreter that makes use of the BASIC in ROM which
those computers have, instead of a clone.

The first "which" immediately following PC, according to Fowler, should
not be replaced with "that", since coming with BASICA instead of GW-BASIC
is true of _all_ genuine IBM PCs, and thus the following clause is not intended
to impose a constraint on "the genuine IBM PC", but is descriptive of a characteristic
they all have.

So in this sense, 'that' is restrictive and 'which' is non-restrictive.

Or perhaps it is more accurate to say that "which" may be used in either
a restrictive or non-restrictive manner, but "that" should only be used in
a restrictive context.

Actually, though, despite Fowler perhaps being in agreement with Strunk & White,
I have to admit I wouldn't have seen anything odd if "that" were used instead
in that position.

John Savard

On Saturday, March 12, 2022 at 9:23:38 PM UTC-7, Quadibloc wrote:

> Actually, though, despite Fowler perhaps being in agreement with Strunk & White,
> I have to admit I wouldn't have seen anything odd if "that" were used instead
> in that position.

And _since_ I think of "which" as a neuter counterpart to some of the uses
of "who", I can see why I'm not in company with Fowler _as well as_ Strunk
& White.

Obviously, one uses "who" in both the restrictive and non-restrictive cases.

An author who rejoices in the surname of Smith...
A black author, who has first-hand experience of racism...

The first phrase is _clearly_ restrictive, whereas the second phrase is
likely at least intended to be thought of as non-restrictive (the author
has experienced racism personally *because he is black*, rather than
simply being a black author who happens to have also personally
experienced racism).

One wouldn't think of using the neuter-appearing "that" in order
to indicate that the first phrase is restrictive.

John Savard

On Saturday, March 12, 2022 at 9:30:44 PM UTC-7, Quadibloc wrote:

Come to think of it, it could be argued that

> An author who rejoices in the surname of Smith...

is non-restrictive, since "an author" is _singular_, and thus we might have
one particular author in mind, such as, say, E. E. "Doc" Smith.

So instead an example of a restrictive phrase would be

Those authors who rejoice in the surname of Smith...

John Savard

On 3/12/2022 7:55 PM, Quadibloc wrote:
> On Friday, March 11, 2022 at 11:37:25 AM UTC-7, Ivan Godard wrote:
>
>> 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.
>
> Of course, "Were I a rich man..." is the subjunctive.
>
> And of course "If I were a rich man..." got a new lease on life from Fiddler
> on the Roof.
>
> John Savard

There seems to have been a difference of opinion among linguists
regarding the conditional. During earlier centuries there was an
academic push to force-fit English into the grammatical structure of
Latin which (apropos this topic) had a subjunctive. Later, as more
far-flung languages were recognized (and not immediately consigned to
the heap of barbarous (look up the derivation of "barbarian" someday for
a giggle) mumblings unfit for English tongues, it was realized that
English was rooted in the Germanic branch of PIE and didn't have Latin
grammar despite the best efforts of Public Schools.

That second look has led to abandoning many strictures - about splitting
infinitives for example - that were artificial Latinizations, among
which was calling the conditional irrealis a subjunctive. However, many
writers (and textbooks) still bandy "subjunctive" about, frequently with
wagging fingers.

For far more than you really want see
https://en.wikipedia.org/wiki/English_subjunctive, especially the
section "Variant terminology and misconceptions".

On 12/03/22 14:42, David Brown wrote:
> On 11/03/2022 13:38, Michael S wrote:
>> On Friday, March 11, 2022 at 2:27:57 PM UTC+2, Michael S wrote:
>>> 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:
>>
> Here's a grammar challenge for you regarding repeated words - can you
> punctuate the following?
>
> Peter where John had had had had had had had had had had had the
> examiners approval
>
>
> (Hint - it's not just one sentence.)
>

These are one sentence, apparently :) I've seen code that is as
difficult to parse and understand as these :(

"In Middle English, there was no difference between & and and, and
and and &, and this situation persists in the present day."

"Wouldn't the sentence 'I want to put two hyphens between the words
Pig and And, and And and Whistle in my Pig-And-Whistle sign' have
been clearer if quotation marks had been placed before Pig, and
between Pig and and, and and and And, and And and and, and and and
And, and And and and, and and and Whistle, and after Whistle?"

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> George Neuner wrote:

[...]

>> 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.

It might also be argued that programming hand-optimized x86 assembly
also needs a special kind of programmer :-)

I know of at least one case where an intern wrote a time-critical
piece of software (a Hough transform for recognizing straight lines)
in AVX2 assembler, leading to a significant piece of software.
He was a bit miffed when the company didn't use the code, but since
he was the only person in the company who could have maintained that
piece of code, it's understandable - it is the nature of interns to
leave :-)

Tom Gardner <spamjunk@blueyonder.co.uk> schrieb:

> "Wouldn't the sentence 'I want to put two hyphens between the words
> Pig and And, and And and Whistle in my Pig-And-Whistle sign' have
> been clearer if quotation marks had been placed before Pig, and
> between Pig and and, and and and And, and And and and, and and and
> And, and And and and, and and and Whistle, and after Whistle?"

I wish the convention of adding parentheses to sentences was
more widespread.

But then Tim would come along and make that a syntax error :-)