On Sunday, October 15, 2023 at 4:48:29 AM UTC-6, Thomas Koenig wrote:

> ColdFire does not implement the whole 68000 instruction set

Precisely, so it won't run AmigaOS.

John Savard

Thomas Koenig wrote:
> MitchAlsup <MitchAlsup@aol.com> schrieb:
>> On Saturday, October 14, 2023 at 1:17:44 PM UTC-5, BGB wrote:
>>> On 10/14/2023 11:33 AM, Michael S wrote:
>>>> On Friday, October 13, 2023 at 9:13:04 PM UTC+3, John Levine wrote:
>>>>> According to John Dallman <j...@cix.co.uk>:
>>>>>> Overall, Oracle's vertical integration plan for making their database
>>>>>> work better on their own hardware was not a success. It turned out that
>>>>>> Oracle DB and SPARC Solaris were already pretty well-tuned for each other,
>>>>>> and there were no easy gains there.
>>>>> What could they do that would make it better than an ARM or RISC V chip
>>>>> running at the same speed? Transactional memory?
>>>>>
>>>>
>>>> It seems, by time of acquisition (late 2009) it was already know internally
>>>> that Rock (SPARC processor with TM support) is doomed. Although it was not
>>>> enounced publicly until next year.
>>>>
>>> I also personally have difficulty imagining what exactly one could do in
>>> a CPU that would give it much advantage for database tasks that would
>>> not otherwise make sense with a general purpose CPU.
>> <
>> Bigger caches and a slower clock rate help data base but do not help general
>> purpose. More slower CPUs and thinner cache hierarchy helps. Less prediction
>> helps too.
>> <
>> So, instead of 64KB L1s and 1MB L2s and 8MB L3s:: do a 256KB L1 and
>> 8MB L2 with no L3s.
>> <
>> It does not mater how fast the clock rate is if you are waiting for memory to
>> respond.
>
> Hm, but 256k L1 would increase the L1 latency, correct?
>
> Maybe this is a reason why SMT is popular in certain processors:
> If a core is waiting for memory, it might as well switch to another
> thread for which the outstanding request has already arrived.
>
> Another reason, I'm told, is that SMT can be a reaction to
> software licensing - some licenses in the commercial field are
> are paid per physical core, and if SMT can squeeze out a few
> percent of performance, even a more expensive processor might be
> more cost-effective.

This is extremely relevant for engineers/engineering software which can
easily run into the $100K/year range for a single license: At those
prices any CPU/motherboard/platform combo which provides at least 10%
speedup is automatically worth $10K more, right?

Terje

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

David Brown <david.brown@hesbynett.no> writes:
>ColdFire is, however, rarely seen these days, and to my knowledge it has
>been many years since any new ColdFire microcontrollers were introduced.

Motorola spun the semiconductor part off as Freescale, and Freescale
was bought by NXP (spun off from Philips). In 2016 or so I heard a
presentation by someone familiar with the microcontroller industry
that NXP is focussing on ARM-based microcontrollers and puts Coldfire
and PowerPC on the back burner.

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

On Sunday, October 15, 2023 at 6:09:05 AM UTC-5, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > On Saturday, October 14, 2023 at 1:17:44 PM UTC-5, BGB wrote:
> >> On 10/14/2023 11:33 AM, Michael S wrote:
> >> > On Friday, October 13, 2023 at 9:13:04 PM UTC+3, John Levine wrote:
> >> >> According to John Dallman <j...@cix.co.uk>:
> >> >>> Overall, Oracle's vertical integration plan for making their database
> >> >>> work better on their own hardware was not a success. It turned out that
> >> >>> Oracle DB and SPARC Solaris were already pretty well-tuned for each other,
> >> >>> and there were no easy gains there.
> >> >> What could they do that would make it better than an ARM or RISC V chip
> >> >> running at the same speed? Transactional memory?
> >> >>
> >> >
> >> > It seems, by time of acquisition (late 2009) it was already know internally
> >> > that Rock (SPARC processor with TM support) is doomed. Although it was not
> >> > enounced publicly until next year.
> >> >
> >> I also personally have difficulty imagining what exactly one could do in
> >> a CPU that would give it much advantage for database tasks that would
> >> not otherwise make sense with a general purpose CPU.
> ><
> > Bigger caches and a slower clock rate help data base but do not help general
> > purpose. More slower CPUs and thinner cache hierarchy helps. Less prediction
> > helps too.
> ><
> > So, instead of 64KB L1s and 1MB L2s and 8MB L3s:: do a 256KB L1 and
> > 8MB L2 with no L3s.
> ><
> > It does not mater how fast the clock rate is if you are waiting for memory to
> > respond.
<
> Hm, but 256k L1 would increase the L1 latency, correct?
<
Not on average, the number of nanoseconds increases, the number of clock
cycles spent doing nothing but waiting decreases.
>
> Maybe this is a reason why SMT is popular in certain processors:
> If a core is waiting for memory, it might as well switch to another
> thread for which the outstanding request has already arrived.
<
As long as you avoid Spectré and Meltdown you can do SMT in the wait
cycles of the other.
>
> Another reason, I'm told, is that SMT can be a reaction to
> software licensing - some licenses in the commercial field are
> are paid per physical core, and if SMT can squeeze out a few
> percent of performance, even a more expensive processor might be
> more cost-effective.
<
Hardware coming to save poorly licensed software--great !!

On Sunday, October 15, 2023 at 2:05:09 AM UTC-5, BGB wrote:
> On 10/14/2023 8:48 PM, MitchAlsup wrote:
> > On Saturday, October 14, 2023 at 1:17:44 PM UTC-5, BGB wrote:
> >> On 10/14/2023 11:33 AM, Michael S wrote:
> >>> On Friday, October 13, 2023 at 9:13:04 PM UTC+3, John Levine wrote:
> >>>> According to John Dallman <j...@cix.co.uk>:
> >>>>> Overall, Oracle's vertical integration plan for making their database
> >>>>> work better on their own hardware was not a success. It turned out that
> >>>>> Oracle DB and SPARC Solaris were already pretty well-tuned for each other,
> >>>>> and there were no easy gains there.
> >>>> What could they do that would make it better than an ARM or RISC V chip
> >>>> running at the same speed? Transactional memory?
> >>>>
> >>>
> >>> It seems, by time of acquisition (late 2009) it was already know internally
> >>> that Rock (SPARC processor with TM support) is doomed. Although it was not
> >>> enounced publicly until next year.
> >>>
> >> I also personally have difficulty imagining what exactly one could do in
> >> a CPU that would give it much advantage for database tasks that would
> >> not otherwise make sense with a general purpose CPU.
> > <
> > Bigger caches and a slower clock rate help data base but do not help general
> > purpose. More slower CPUs and thinner cache hierarchy helps. Less prediction
> > helps too.
> > <
> > So, instead of 64KB L1s and 1MB L2s and 8MB L3s:: do a 256KB L1 and
> > 8MB L2 with no L3s.
> > <
> > It does not mater how fast the clock rate is if you are waiting for memory to
> > respond.
> OK.
>
> In my own use-cases, 16/32/64K seemed near optimal, but I guess if the
> working sets are larger, this could favor bigger L1s.
<
Take your application and add a level of indirection for every LD, every ST
and every Branch, and see how your cache hierarchy works then.
>
> It had seemed like, at 32 or 64K, one tends towards a 98 or 99% hit-rate.
>
For your games, yes; for billion transactions per hour data base, decidedly no.
>
> In the past, my attempts to increase MHz tended to come at the cost of
> significant reduction to L1 cache size (mostly, the "magic" being to
> make it small enough to fit effectively into LUTRAMs).
>
> The disadvantage being that this offsets any gains from more MHz in
> terms of more cycles spent in cache misses.
<
Data base SW architecture makes one revisit cache hierarrchy and CPU
frequency.
>
> I now have it "mostly working" (with the bigger caches), but still need
> to determine if "more MHz" is enough to offset the significant increase
> in clock cycles spent on interlock / register-RAW stalls. Still falls
> short of consistently passing timing though (and also currently lacks
> the low-precision FP-SIMD unit).
>
> As-is:
> Losses (for now):
> Disabled dedicated FP-SIMD unit (*2);
> Many more ops have higher latency;
> Dropped RISC-V support and 96-bit address space support for now;
> No more LDTEX instruction for now;
> Back to no FDIV or FSQRT ops;
> ...
> Partial:
> Compare-Branch reduced to compare-with-zero only;
> For now, have disabled 128-bit ALU operations.
>
> Running the ringbus and L2 cache at higher clock-speeds does seem to
> have increased memory bandwidth (including for accessing external RAM).
>
> *2: Pulling off single-precision operations in a 3 cycle latency at
> 75MHz seemed to still be asking a bit too much.
>
>
>
> But, on the other side, dropping MHz to allow bigger L1s could also make
> sense, if the code has a naturally higher L1 miss rate.
>
>
> In my own use cases, 33 or 25 MHz wouldn't allow much gain over 50MHz,
> apart from the ability to possibly pull off fully pipelined
> double-precision FPU operations or similar.
> >>
> >> I would expect database workloads to be primarily dominated by memory
> >> and IO.
> > <
> > More so memory and less so I/O once they got main memories in the TB region.
> > Those TBs of main memory are used like the older index partitions on disks.
> Hmm...
>
> I still have 48GB; and (on average) the most RAM-intensive thing I tend
> to do is running Firefox (well, except in rare cases where I try to
> recompile LLVM and it brings my computer to its knees, *).
<
In a data base system, one might find 16 of those GBs spent in DB indexing
structures. So, every LD. ST, and Branch touches one of those DW in that
16 GB address (sub)space before going it where it really wanted to be.
>

> > Why do you think this is a job for a CPU ??
<
> I hadn't heard of there being anything else to run the B-Tree walks...
<
IBM used to have channels where one could send a "find record "AbcdEFG"
and read record into *buffer" command.
>
> It seemed like one would need a mechanism for hopefully moderately
> efficient "strncmp()" and similar though...

On Sunday, October 15, 2023 at 7:55:41 PM UTC+3, Anton Ertl wrote:
> David Brown <david...@hesbynett.no> writes:
> >ColdFire is, however, rarely seen these days, and to my knowledge it has
> >been many years since any new ColdFire microcontrollers were introduced.
> Motorola spun the semiconductor part off as Freescale, and Freescale
> was bought by NXP (spun off from Philips). In 2016 or so I heard a
> presentation by someone familiar with the microcontroller industry
> that NXP is focussing on ARM-based microcontrollers and puts Coldfire
> and PowerPC on the back burner.

For new stuff - sure.
But old stuff still sold and still useful.
We had few designs (still produced occasionally) base on ColdFire MCU,
because back then they were the only 32-bit MCUs available for low volume
purchaser that had integrated Fast Ethernet phy.
Soon thereafter Ti launched Arm-based Tiva series with similar capabilities
and that's what we prefer now when we need MCU with Ethernet and care about
design time more than about few dollars of BoM.
But it seems (I didn't really look in last couple of years) that in NXP portfolio
integrated Ethernet phy is still available only with Coldfire.

ColdFire.

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

On Sat, 14 Oct 2023 13:17:33 -0500, BGB <cr88192@gmail.com> wrote:

>I also personally have difficulty imagining what exactly one could do in
>a CPU that would give it much advantage for database tasks that would
>not otherwise make sense with a general purpose CPU.
>
>I would expect database workloads to be primarily dominated by memory
>and IO.
>
>So, it seems like one would mostly just want a CPU with significant
>memory bandwidth and similar. Maybe some helper operations for things
>like string compare and similar.
>
>
>Though, assuming the B-Tree's were structured in an appropriate way,
>things like "packed search" / "packed compare" instructions could be useful.
>
>For example, I already had some instructions for looking up values
>within packed-integer values, partly related to some cases I had used
>B-Trees (and can also be used to help with implementing string operations).
>
>
>I suspect this would be less useful for an actual database though, since
>AFAIK, most people are using things like CHARACTER/VARCHAR or similar
>for primary keys, whereas packed-compare would mostly only be
>particularly useful if someone were using SMALLINT or INTEGER for their
>primary keys.
>
> :
>
>But, yeah, the main reason it might make sense to put integer primary
>keys before the row data or similar, is that it could allow for more
>efficient binary search. But... could only work effectively if a person
>uses an integer field or similar for a primary key, and not an ASCII
>string or similar (where one may as well use the latter).

There are exceptions, but "string" like fields should (almost) never
be the /primary/ key or used for a foreign key. However, it does make
sense to be able to index them effectively for searching.

On 15/10/2023 18:47, Anton Ertl wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> ColdFire is, however, rarely seen these days, and to my knowledge it has
>> been many years since any new ColdFire microcontrollers were introduced.
>
> Motorola spun the semiconductor part off as Freescale, and Freescale
> was bought by NXP (spun off from Philips). In 2016 or so I heard a
> presentation by someone familiar with the microcontroller industry
> that NXP is focussing on ARM-based microcontrollers and puts Coldfire
> and PowerPC on the back burner.
>

That's right.

At one point, Freescale had 4 processor architectures - PowerPC,
68k/ColdFire, MCore and ARM. It was not practical, and MCore was the
first to go. I never used MCore, nor did I know anyone who did, but
I've used all the others to some extent. The 68332 microcontroller was
brilliant, and is still being made after about 30 years - despite
Motorola trying to kill it off in favour of PowerPC microcontrollers.
They don't make so many new PowerPC microcontrollers now, but the
automotive and high-reliability industries are a conservative bunch, and
many don't trust the "newcomer" ARM as much as they trust PowerPC.

On 15/10/2023 17:53, Quadibloc wrote:
> On Sunday, October 15, 2023 at 4:48:29 AM UTC-6, Thomas Koenig wrote:
>
>> ColdFire does not implement the whole 68000 instruction set
>
> Precisely, so it won't run AmigaOS.
>

You can always use an "unimplemented instruction" exception handler :-)

On Sat, 14 Oct 2023 14:27:35 -0700, "Chris M. Thomasson"
<chris.m.thomasson.1@gmail.com> wrote:

>Never liked TM, even when it was STM.

At least with STM you can diagnose the reason for failure. Finding a
bug with (or worse, in) HTM is darn near impossible.

When used properly for optimistic concurrency, any kind of TM can make
the programmer's job easier and the code clearer ... which often is
more important than execution speed.

It falls down hard when it is mistaken for dbms-like transactions.

My problem with (otherwise working) HTM is the limits ... sometimes
the data "elements" that need to be tracked simply are too large, and
other times there simply are too many of them.

STM can relax limits enough to be useful [if not particularly fast].

YMMV.

On 10/15/2023 12:22 PM, MitchAlsup wrote:
> On Sunday, October 15, 2023 at 6:09:05 AM UTC-5, Thomas Koenig wrote:
>> MitchAlsup <Mitch...@aol.com> schrieb:
>>> On Saturday, October 14, 2023 at 1:17:44 PM UTC-5, BGB wrote:
>>>> On 10/14/2023 11:33 AM, Michael S wrote:
>>>>> On Friday, October 13, 2023 at 9:13:04 PM UTC+3, John Levine wrote:
>>>>>> According to John Dallman <j...@cix.co.uk>:
>>>>>>> Overall, Oracle's vertical integration plan for making their database
>>>>>>> work better on their own hardware was not a success. It turned out that
>>>>>>> Oracle DB and SPARC Solaris were already pretty well-tuned for each other,
>>>>>>> and there were no easy gains there.
>>>>>> What could they do that would make it better than an ARM or RISC V chip
>>>>>> running at the same speed? Transactional memory?
>>>>>>
>>>>>
>>>>> It seems, by time of acquisition (late 2009) it was already know internally
>>>>> that Rock (SPARC processor with TM support) is doomed. Although it was not
>>>>> enounced publicly until next year.
>>>>>
>>>> I also personally have difficulty imagining what exactly one could do in
>>>> a CPU that would give it much advantage for database tasks that would
>>>> not otherwise make sense with a general purpose CPU.
>>> <
>>> Bigger caches and a slower clock rate help data base but do not help general
>>> purpose. More slower CPUs and thinner cache hierarchy helps. Less prediction
>>> helps too.
>>> <
>>> So, instead of 64KB L1s and 1MB L2s and 8MB L3s:: do a 256KB L1 and
>>> 8MB L2 with no L3s.
>>> <
>>> It does not mater how fast the clock rate is if you are waiting for memory to
>>> respond.
> <
>> Hm, but 256k L1 would increase the L1 latency, correct?
> <
> Not on average, the number of nanoseconds increases, the number of clock
> cycles spent doing nothing but waiting decreases.

Yeah, that makes sense. Huge L1's, less MHz, fewer miss penalties if the
working set is huge.

With 256K, one could potentially fit something like a Deflate
encoder/decoder entirely into the L1 cache as well.

>>
>> Maybe this is a reason why SMT is popular in certain processors:
>> If a core is waiting for memory, it might as well switch to another
>> thread for which the outstanding request has already arrived.
> <
> As long as you avoid Spectré and Meltdown you can do SMT in the wait
> cycles of the other.
>>
>> Another reason, I'm told, is that SMT can be a reaction to
>> software licensing - some licenses in the commercial field are
>> are paid per physical core, and if SMT can squeeze out a few
>> percent of performance, even a more expensive processor might be
>> more cost-effective.
> <
> Hardware coming to save poorly licensed software--great !!

I haven't really used any software like this.

For nearly everything, it seems like there is open-source alternatives,
and if there is not, one could in theory write something and then post
it on the internet.

Granted, I guess I can note that there seems to be a significant lack of
"not awful" open-source 3D modeling and solid-modeling software.

....

On 10/15/2023 12:36 PM, George Neuner wrote:
> On Sat, 14 Oct 2023 13:17:33 -0500, BGB <cr88192@gmail.com> wrote:
>
>
>> I also personally have difficulty imagining what exactly one could do in
>> a CPU that would give it much advantage for database tasks that would
>> not otherwise make sense with a general purpose CPU.
>>
>> I would expect database workloads to be primarily dominated by memory
>> and IO.
>>
>> So, it seems like one would mostly just want a CPU with significant
>> memory bandwidth and similar. Maybe some helper operations for things
>> like string compare and similar.
>>
>>
>> Though, assuming the B-Tree's were structured in an appropriate way,
>> things like "packed search" / "packed compare" instructions could be useful.
>>
>> For example, I already had some instructions for looking up values
>> within packed-integer values, partly related to some cases I had used
>> B-Trees (and can also be used to help with implementing string operations).
>>
>>
>> I suspect this would be less useful for an actual database though, since
>> AFAIK, most people are using things like CHARACTER/VARCHAR or similar
>> for primary keys, whereas packed-compare would mostly only be
>> particularly useful if someone were using SMALLINT or INTEGER for their
>> primary keys.
>>
>> :
>>
>> But, yeah, the main reason it might make sense to put integer primary
>> keys before the row data or similar, is that it could allow for more
>> efficient binary search. But... could only work effectively if a person
>> uses an integer field or similar for a primary key, and not an ASCII
>> string or similar (where one may as well use the latter).
>
> There are exceptions, but "string" like fields should (almost) never
> be the /primary/ key or used for a foreign key. However, it does make
> sense to be able to index them effectively for searching.
>

Yeah.

I guess, if I were designing something, likely integer fields would be
used for primary keys (or index keys, if the primary key is not an
integer type).

Possibly, secondary index B-Tree's could either map string fields to the
index key/primary key; and also for implementing foreign keys, ...

Less sure how one would go about efficiently implementing queries by
non-unique fields though, say:
select * from Workers where FirstName='James'
Or similar...

In a naive implementation, something like this would likely require
walking every row in the table to perform the query.

Otherwise, one would likely need to build lists of rows which have a
given field row, or alternatively use hash-chains or similar in addition
to B-Trees. Would need to come up with a hash-chain structure that deals
well with arbitrary scalability. One could possibly build hash-chains on
top of a B-Tree, but this seems inefficient (say, one builds a
linked-list for each hash-chain segment on top of a B-Tree, with each
segment containing 0..N index keys for rows where this field matches the
corresponding hash).

But, yeah, in terms of the CPU, still it seems like all this mostly
amounts to designing the CPU mostly to optimize for large working sets;
rather than any particular ISA feature (say, the typical SIMD
shenanigans or similar; where things like floating-point SIMD are
unlikely to be particularly useful for database workloads, ...).

....

According to John Dallman <jgd@cix.co.uk>:
>In article <363a3f9d-f061-4eda-8a75-61215d491f4cn@googlegroups.com>,
>already5chosen@yahoo.com (Michael S) wrote:
>
>> Back then common wisdom was that Oracle bought Sun Microsystems
>> first and foremost because they owned mySQL.
>
>That never seemed plausible to me. The amount of money involved, and the
>limited control over mySQL they'd get, just didn't seem to make sense.

It makes sense as a way to ensure that MySQL never became a serious competitor
to Oracle. They segmented the market, very low end to free MySQL, low end
to paid MySQL, high end to Oracle. Yeah, the MySQL people left and now we
have Mariadb and Percona further splitting the low end.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 10/15/2023 10:21 AM, John Dallman wrote:
> In article <c2399332-9696-4749-adc4-8d9b071c060dn@googlegroups.com>,
> already5chosen@yahoo.com (Michael S) wrote:
>
>>> Growing, but not yet fully-established: RISC-V.
>> Is RISC-V really present in general-purpose computing?
>
> Not yet, but it seems to have an adequate design and enough momentum to
> get there. /Staying/ there is a different question.
>

I suspect that some of the weak areas of RISC-V will likely become more
obvious as they attempt higher performance implementations.

Then again, given it lacks condition codes or similar, this may
potentially allow it to get higher clock-speeds to compensate for some
other issues (relative to condition-code based ISAs, where condition
codes seem like a pretty steep weight in my limited experience).

Then again, I am left recently thinking about how I would design an ISA
and CPU core to try to sustain higher clock-speeds (my existing design
seems to point out some weak areas regarding clock-speed, and my
fiddling at trying to boost the clock-speed is pointing out some things
that "could have been done differently" in terms of the ISA design).

Say, had some things been done differently, if 75MHz would have been
easier to achieve on an FPGA, or 100MHz in reach (assuming sticking with
a 3-wide 64-bit design and 32K L1 caches and similar).

Like, for example, I have noted that, as-is, determining bundle length
seems to be a bit too steep (too many input bits need to be considered).
There is generally a bit much latency in the instruction decoders as
well, ...

Though, I suspect some latency could be reduced by going over to an "XG2
only" ISA variant, which would likely eliminate some of the latency here
(would remove ~ 4 bits per instruction-word for length determination,
and simplify the logic for unpacking register fields, ...).

Though, one weak area is that one still needs to remap register fields
to ports (based on opcode and bundle layout) and that the interpretation
of the immediate field depends on the opcode. No way around this as-is
(in a partial redesign, the idea would be to move over to defining
immediate fields in terms of the instruction block, and moving over to
zero-extended immediate values for everything other than
branch-displacements and jumbo-forms).

Though, I did recently make another random observation that helped
somewhat with timing:
Transforming stuff like:
...
always @(posedge clock)
begin
if(!exHold)
begin
tFoo <= tNxtFoo;
...
end
...
end
Into:
wire exHoldN = !exHold;
...
always @(posedge clock)
begin
if(exHoldN)
begin
tFoo <= tNxtFoo;
...
end
...
end

Resulted in some noticeable gains, as in the former case, it seems like
this resulted in high fanout "LUT1" routed into the "Clock-Enable" pin
on each of the flip-flops, whereas inverting the signal via the "wire"
declaration seemingly instead inverts the signal in the LUTs that
produce it (reducing the path length, ...).

It starts to seem like the logic synthesis is less clever sometimes than
it may seem at first...

Unlike RISC-V, I am still inclined to consider "relative compare and
branch" to be a "No, don't do it!" feature (*1).

Better in terms of latency to have "compare with zero and branch", which
avoids the "evilness" of needing to have a carry chain to determine
whether or not to branch.

Granted, one will still end up likely needing something akin to RISC-V's
"SLT" instruction, since "SUB + Bxx" with "compare with zero" logic
can't deal with the full dynamic range of an integer register (so, one
would need "SLT+BZ/BNZ" instead).

Granted, if most of the relative compares are between 32-bit values, and
one has 64-bit registers, then "SUB+Bxx" would be sufficient for these
cases.

*1: This has a higher cost than other options and only addresses a small
number of cases that couldn't be handled with the same instruction-count
via the other option (with the partial exception if one has a 1-cycle
constant load, 2-cycle ALU ops, and the branch has the same latency
either way).

Still somewhat in favor of having indexed addressing though, as IME, a
"not exactly small" proportion of the loads/stores tend to use it (and
"it doesn't really cost much" relative to fixed constant displacements).

Still sort of in favor of keeping predication, but might be tempted to
consider making the SR.T bit exclusively used for predication (apart
from CMPxx and TST, no other instructions would touch it).

Though, could possibly make sense to consider consolidating "predicate
stack manipulation" into the CMPxx instructions:
CMPxx // T = Rs xx Rt
CMPTAxx // T = T && (Rs xx Rt)
CMPTOxx // T = T || (Rs xx Rt)
CMPUAxx // T = U[0] && (Rs xx Rt)
CMPUOxx // T = U[0] || (Rs xx Rt)
CMPTPSAxx // U'={U[6:0], T}, T = T && (Rs xx Rt)
CMPTPSOxx // U'={U[6:0], T}, T = T || (Rs xx Rt)
CMPUPPAxx // T = U[0] && (Rs xx Rt), U={0, U[7:1]}
CMPUPPOxx // T = U[0] || (Rs xx Rt), U={0, U[7:1]}
...

Basically, because this can (in theory) allow predication to deal with
nested if/else blocks with less encoding-space overhead than the use of
dedicated predicate-bit registers (as was used in IA-64 or similar).

But, with the obvious drawback of being a stack model (and not allowing
instruction scheduling between different if/else blocks).

Well, and may not offer much advantage over my past (mostly failed)
experiment of "SR twiddle" instructions (apart from trying to merge the
twiddle into the compare itself; thus avoiding the overhead of needing
separate instructions to perform this twiddling). And, usually by the
time one is needing to deal with nested if/else blocks, it is "better"
to deal with the outer levels via a branch anyways.

....

But, getting non-terrible performance is still difficult it seems.

>>> In established niches, but not growing out of them: POWER, IBM Z.
>> IBM POWER - not sure about it. POWER holds on for as long as IBM
>> able to make POWER chips that are competitive (or better exceeding)
>> x86-64 and ARM64 in absolute performance and at the same time not
>> ridiculously behind in price/performance. It looks to me like POWER
>> is in the same rat race that effectively killed SPARC and IPF. They
>> just manage to run a little better.
>
> It's also used to run IBM i, which is a pretty big niche that's quite
> easy to forget. It could be replaced, since the concept of the system is
> that the hardware is replaceable, but IBM would try hard to avoid the
> costs of doing that.
>

Yep.

> John

On 10/14/2023 6:49 PM, MitchAlsup wrote:
> On Saturday, October 14, 2023 at 4:21:44 PM UTC-5, Anton Ertl wrote:
>> Michael S <already...@yahoo.com> writes:
>>
>> Makes me wonder how well TM worked on SPARC.
> <
> Not well enough to overcome the slow performance levels of SPARC CPUs.

Fwiw... I won a SunFire T2000 from Suns CoolThreads context with my
vZoom project.

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

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> Thomas Koenig wrote:

>> Another reason, I'm told, is that SMT can be a reaction to
>> software licensing - some licenses in the commercial field are
>> are paid per physical core, and if SMT can squeeze out a few
>> percent of performance, even a more expensive processor might be
>> more cost-effective.
>
> This is extremely relevant for engineers/engineering software which can
> easily run into the $100K/year range for a single license: At those
> prices any CPU/motherboard/platform combo which provides at least 10%
> speedup is automatically worth $10K more, right?

Yes (although it depends a bit on how the software is used; it is
not a big difference if the user is made to wait a few seconds more
in an interactive session, a different matter if there is time
pressure and/or the software is running for a very long time).

But the thing that bugs me most about most commercial software is
license managers. These are a pest. Working on a problem with
these is extremely aggravating, because it is _completely_ wasted -
I am spending time on a piece of software that is designed to keep
me from working (and often does, although my company paid the money
for it).

If there ever is a reason for switching to open source where it is
available, it is license managers.

On Sunday, October 15, 2023 at 3:05:42 PM UTC-5, BGB wrote:
> On 10/15/2023 10:21 AM, John Dallman wrote:
> > In article <c2399332-9696-4749...@googlegroups.com>,
> > already...@yahoo.com (Michael S) wrote:
> >
> >>> Growing, but not yet fully-established: RISC-V.
> >> Is RISC-V really present in general-purpose computing?
> >
> > Not yet, but it seems to have an adequate design and enough momentum to
> > get there. /Staying/ there is a different question.
> >
> I suspect that some of the weak areas of RISC-V will likely become more
> obvious as they attempt higher performance implementations.
<
One of the weak areas in RISC-V is that most of the investment comes from China.
>
> Then again, given it lacks condition codes or similar, this may
> potentially allow it to get higher clock-speeds to compensate for some
> other issues (relative to condition-code based ISAs, where condition
> codes seem like a pretty steep weight in my limited experience).
>
If condition codes make or break your design, it was already broken.
>
>
> Then again, I am left recently thinking about how I would design an ISA
> and CPU core to try to sustain higher clock-speeds (my existing design
> seems to point out some weak areas regarding clock-speed, and my
> fiddling at trying to boost the clock-speed is pointing out some things
> that "could have been done differently" in terms of the ISA design).
>
> Say, had some things been done differently, if 75MHz would have been
> easier to achieve on an FPGA, or 100MHz in reach (assuming sticking with
> a 3-wide 64-bit design and 32K L1 caches and similar).
>
> Like, for example, I have noted that, as-is, determining bundle length
> seems to be a bit too steep (too many input bits need to be considered).
> There is generally a bit much latency in the instruction decoders as
> well, ...
>
> Though, I suspect some latency could be reduced by going over to an "XG2
> only" ISA variant, which would likely eliminate some of the latency here
> (would remove ~ 4 bits per instruction-word for length determination,
> and simplify the logic for unpacking register fields, ...).
>
> Though, one weak area is that one still needs to remap register fields
> to ports (based on opcode and bundle layout) and that the interpretation
> of the immediate field depends on the opcode.
<
Gack:: {And this is something that irks me about ROSC-V compressed::}
<
If your source register fields move around, you have to do a partial decode
in order to route the bits to the register file select line decoder. This adds
at least 4 gates of delay (¼ cycle) between the point where inst resolves,
and you start moving the select line that will ultimately read its value out
to a register operand.
<
> No way around this as-is
> (in a partial redesign, the idea would be to move over to defining
> immediate fields in terms of the instruction block, and moving over to
> zero-extended immediate values for everything other than
> branch-displacements and jumbo-forms).
>
You must leave the register specification fields in fixed positions {if you
want a fast decode}.
>
> Though, I did recently make another random observation that helped
> somewhat with timing:
> Transforming stuff like:
> ...
> always @(posedge clock)
> begin
> if(!exHold)
> begin
> tFoo <= tNxtFoo;
> ...
> end
> ...
> end
> Into:
> wire exHoldN = !exHold;
> ...
> always @(posedge clock)
> begin
> if(exHoldN)
> begin
> tFoo <= tNxtFoo;
> ...
> end
> ...
> end
<
See !! you moved the sampling of exHold before the clock edge, taking
at least 1 gate of delay out of the subsequent cycle.
>
> Resulted in some noticeable gains, as in the former case, it seems like
> this resulted in high fanout "LUT1" routed into the "Clock-Enable" pin
> on each of the flip-flops, whereas inverting the signal via the "wire"
> declaration seemingly instead inverts the signal in the LUTs that
> produce it (reducing the path length, ...).
>
> It starts to seem like the logic synthesis is less clever sometimes than
> it may seem at first...
>
If you have clock edges in the code, synthesis has little choice.
>
>
> Unlike RISC-V, I am still inclined to consider "relative compare and
> branch" to be a "No, don't do it!" feature (*1).
<
Originally, this a cross product of MIPS R2000 design point where the L1 cache
was shared as I$ and D$ on alternate phases--and having these paths both
take exactly 2 cycles. If this represents your pipeline(s), then the trick buys
maybe 5%, if it does not fit your pipeline(s) you tend to loose 5%-ish; because
either FETCH of LD gets a cycle added.
>
> Better in terms of latency to have "compare with zero and branch", which
> avoids the "evilness" of needing to have a carry chain to determine
> whether or not to branch.
<
This works will all pipeline design points, whereas the other works only
with I$ disjoint from D$ designs.
>
> Granted, one will still end up likely needing something akin to RISC-V's
> "SLT" instruction, since "SUB + Bxx" with "compare with zero" logic
> can't deal with the full dynamic range of an integer register (so, one
> would need "SLT+BZ/BNZ" instead).
<
Why not an instruction that sets all integral comparison patterns and
a branch that samples one (or more).
>
> Granted, if most of the relative compares are between 32-bit values, and
> one has 64-bit registers, then "SUB+Bxx" would be sufficient for these
> cases.
>
> *1: This has a higher cost than other options and only addresses a small
> number of cases that couldn't be handled with the same instruction-count
> via the other option (with the partial exception if one has a 1-cycle
> constant load, 2-cycle ALU ops, and the branch has the same latency
> either way).
>
>
> Still somewhat in favor of having indexed addressing though, as IME, a
> "not exactly small" proportion of the loads/stores tend to use it (and
> "it doesn't really cost much" relative to fixed constant displacements).
<
When it does get used, and you don't have it, you eat an instruction.
Which has to be fetched, decoded, executed, forwarding its result, later
written into RF, compared to simply having bits fetched, and tagging along
the pipeline doing no forwarding and no RF write. So, even it it only gets
used (say) 2% of the time, It can save 6% power (or more).
>
> Still sort of in favor of keeping predication, but might be tempted to
> consider making the SR.T bit exclusively used for predication (apart
> from CMPxx and TST, no other instructions would touch it).
>
> Though, could possibly make sense to consider consolidating "predicate
> stack manipulation" into the CMPxx instructions:
> CMPxx // T = Rs xx Rt
> CMPTAxx // T = T && (Rs xx Rt)
> CMPTOxx // T = T || (Rs xx Rt)
> CMPUAxx // T = U[0] && (Rs xx Rt)
> CMPUOxx // T = U[0] || (Rs xx Rt)
> CMPTPSAxx // U'={U[6:0], T}, T = T && (Rs xx Rt)
> CMPTPSOxx // U'={U[6:0], T}, T = T || (Rs xx Rt)
> CMPUPPAxx // T = U[0] && (Rs xx Rt), U={0, U[7:1]}
> CMPUPPOxx // T = U[0] || (Rs xx Rt), U={0, U[7:1]}
> ...
>
> Basically, because this can (in theory) allow predication to deal with
> nested if/else blocks with less encoding-space overhead than the use of
> dedicated predicate-bit registers (as was used in IA-64 or similar).
<
IMNSHO:: you are putting the xx bits in the CMP instruction rather than putting
them in the BB (or PB) instruction; where the room for the bits is less costly.
<
CMP Rt,Rs1,Rs2
BB xx,Label
>
> But, with the obvious drawback of being a stack model (and not allowing
> instruction scheduling between different if/else blocks).
>
> Well, and may not offer much advantage over my past (mostly failed)
> experiment of "SR twiddle" instructions (apart from trying to merge the
> twiddle into the compare itself; thus avoiding the overhead of needing
> separate instructions to perform this twiddling). And, usually by the
> time one is needing to deal with nested if/else blocks, it is "better"
> to deal with the outer levels via a branch anyways.
>
>
> ...
>
> But, getting non-terrible performance is still difficult it seems.
> >>> In established niches, but not growing out of them: POWER, IBM Z.
> >> IBM POWER - not sure about it. POWER holds on for as long as IBM
> >> able to make POWER chips that are competitive (or better exceeding)
> >> x86-64 and ARM64 in absolute performance and at the same time not
> >> ridiculously behind in price/performance. It looks to me like POWER
> >> is in the same rat race that effectively killed SPARC and IPF. They
> >> just manage to run a little better.
> >
> > It's also used to run IBM i, which is a pretty big niche that's quite
> > easy to forget. It could be replaced, since the concept of the system is
> > that the hardware is replaceable, but IBM would try hard to avoid the
> > costs of doing that.
> >
> Yep.
>
>
> > John

John Levine wrote:
> According to John Dallman <jgd@cix.co.uk>:
>> In article <363a3f9d-f061-4eda-8a75-61215d491f4cn@googlegroups.com>,
>> already5chosen@yahoo.com (Michael S) wrote:
>>
>>> Back then common wisdom was that Oracle bought Sun Microsystems
>>> first and foremost because they owned mySQL.
>>
>> That never seemed plausible to me. The amount of money involved, and the
>> limited control over mySQL they'd get, just didn't seem to make sense.
>
> It makes sense as a way to ensure that MySQL never became a serious competitor
> to Oracle. They segmented the market, very low end to free MySQL, low end
> to paid MySQL, high end to Oracle. Yeah, the MySQL people left and now we
> have Mariadb and Percona further splitting the low end.
>
Personally I switched to MariaDB as soon as that became available,
professionally Postgres is doing everything I need, including stuff like
GeoSpatial data handling/datum transforms/queries.

Terje

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

Thomas Koenig wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
>> Thomas Koenig wrote:
>
>>> Another reason, I'm told, is that SMT can be a reaction to
>>> software licensing - some licenses in the commercial field are
>>> are paid per physical core, and if SMT can squeeze out a few
>>> percent of performance, even a more expensive processor might be
>>> more cost-effective.
>>
>> This is extremely relevant for engineers/engineering software which can
>> easily run into the $100K/year range for a single license: At those
>> prices any CPU/motherboard/platform combo which provides at least 10%
>> speedup is automatically worth $10K more, right?
>
> Yes (although it depends a bit on how the software is used; it is
> not a big difference if the user is made to wait a few seconds more
> in an interactive session, a different matter if there is time
> pressure and/or the software is running for a very long time).
>
> But the thing that bugs me most about most commercial software is
> license managers. These are a pest. Working on a problem with
> these is extremely aggravating, because it is _completely_ wasted -
> I am spending time on a piece of software that is designed to keep
> me from working (and often does, although my company paid the money
> for it).
>
> If there ever is a reason for switching to open source where it is
> available, it is license managers.

Back when I was at Hydro, my brother Knut who was at the same company
working on optimizing fertilizer plants would need help every couple of
years: Every time AspenTech had an update to their license manager, we
had to figure out again how to get it to work.

In my previous job as CTO of Open iT, we made a (good!) living from
helping companies figure out how to pay less for their engineering
software licenses, our main source of information was the
(debug/regular) logs from the license managers. Before I left we were
supporting over 30 different license managers, we had to reverse
engineer incompatible modifications to the log formats every few months.

If you are ever in a situation where you are spending $Millions on
licensed software, _please_ get in contact with Open iT! (Or one of the
competitors, although I think Open iT which was the first to do this is
still the best).

Large companies like Maersk have gone public with their payback from
this kind of optimization: ROI of over 20X in just the first year,
including not just the Open iT software but also all internal and
external project costs. Subsequent years would be even better obviously.

Terje

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

On 16/10/2023 08:52, Terje Mathisen wrote:
> John Levine wrote:
>> According to John Dallman <jgd@cix.co.uk>:
>>> In article <363a3f9d-f061-4eda-8a75-61215d491f4cn@googlegroups.com>,
>>> already5chosen@yahoo.com (Michael S) wrote:
>>>
>>>> Back then common wisdom was that Oracle bought Sun Microsystems
>>>> first and foremost because they owned mySQL.
>>>
>>> That never seemed plausible to me. The amount of money involved, and the
>>> limited control over mySQL they'd get, just didn't seem to make sense.
>>
>> It makes sense as a way to ensure that MySQL never became a serious
>> competitor
>> to Oracle.  They segmented the market, very low end to free MySQL, low
>> end
>> to paid MySQL, high end to Oracle.  Yeah, the MySQL people left and
>> now we
>> have Mariadb and Percona further splitting the low end.
>>
> Personally I switched to MariaDB as soon as that became available,
> professionally Postgres is doing everything I need, including stuff like
> GeoSpatial data handling/datum transforms/queries.
>

PostgreSQL has always been much more upmarket and professional than
MySQL, and must surely have been far more of an alternative to Oracle
than MySQL ever was. People who use MySQL and are happy with its
feature set would not have the budget for Oracle for the task. But
PostgreSQL is much more feature-comparable to Oracle or MS SQL Server as
a database server - the key limitation is in the development and
administration tools.

On Sunday, October 15, 2023 at 4:02:31 PM UTC+3, EricP wrote:
> Michael S wrote:
> > On Sunday, October 15, 2023 at 4:49:12 AM UTC+3, MitchAlsup wrote:
> >> On Saturday, October 14, 2023 at 4:21:44 PM UTC-5, Anton Ertl wrote:
> >>> Michael S <already...@yahoo.com> writes:
> >>>
> >>> Makes me wonder how well TM worked on SPARC.
> >> <
> >> Not well enough to overcome the slow performance levels of SPARC CPUs.
> >
> > How do you know?
> > Remember, SPARC with HTM never reached customers.
> Sun Rock supposedly had HTM and was manufactured
> but I see reference to being canceled by Oracle.
>

Formally it was canceled by Oracle in 2010.
In reality it was canceled almost a year earlier, probably few weeks before
announcement of acquisition.
Rock's chief Marc Tremblay left Sun in April 2009.

> Rock: A High-Performance Sparc CMT Processor, 2009
> https://www.kth.se/social/upload/4fb51486f27654119b000007/rock_computer.pdf
>
> The HTM was basically the same as AMDs ASF and Intels RTM
> that used cache line invalidate messages to abort the transaction.
> As such it was a "new contender wins" try-fail-retry algorithm
> and would likely have had the same usability problems as RTM.

On 15/10/2023 22:44, Thomas Koenig wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
>> Thomas Koenig wrote:
>
>>> Another reason, I'm told, is that SMT can be a reaction to
>>> software licensing - some licenses in the commercial field are
>>> are paid per physical core, and if SMT can squeeze out a few
>>> percent of performance, even a more expensive processor might be
>>> more cost-effective.
>>
>> This is extremely relevant for engineers/engineering software which can
>> easily run into the $100K/year range for a single license: At those
>> prices any CPU/motherboard/platform combo which provides at least 10%
>> speedup is automatically worth $10K more, right?
>
> Yes (although it depends a bit on how the software is used; it is
> not a big difference if the user is made to wait a few seconds more
> in an interactive session, a different matter if there is time
> pressure and/or the software is running for a very long time).
>
> But the thing that bugs me most about most commercial software is
> license managers. These are a pest. Working on a problem with
> these is extremely aggravating, because it is _completely_ wasted -
> I am spending time on a piece of software that is designed to keep
> me from working (and often does, although my company paid the money
> for it).
>
> If there ever is a reason for switching to open source where it is
> available, it is license managers.

At least these days we rarely have to deal with parallel port dongles!

One big-name embedded toolchain company I knew of had a larger support
department for dealing with licensing and dongle problems than their
department for technical support for the actual toolchain.

On Mon, 16 Oct 2023 09:32:56 +0200, David Brown
<david.brown@hesbynett.no> wrote:

>PostgreSQL has always been much more upmarket and professional than
>MySQL, and must surely have been far more of an alternative to Oracle
>than MySQL ever was. People who use MySQL and are happy with its
>feature set would not have the budget for Oracle for the task. But
>PostgreSQL is much more feature-comparable to Oracle or MS SQL Server as
>a database server - the key limitation is in the development and
>administration tools.

Postgresql is much more capable than mySQL, but that capability comes
with a cost: Postgresql uses process parallelism - it is not
multithreaded and so uses more per-connection resources than does
mySQL. Postgresql often needs front-end connection pooling in
situations where mySQL would not, so even small installations can get
complicated.

I prefer Postgresql, but YMMV.

On 16/10/2023 16:38, George Neuner wrote:
> On Mon, 16 Oct 2023 09:32:56 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
>
>> PostgreSQL has always been much more upmarket and professional than
>> MySQL, and must surely have been far more of an alternative to Oracle
>> than MySQL ever was. People who use MySQL and are happy with its
>> feature set would not have the budget for Oracle for the task. But
>> PostgreSQL is much more feature-comparable to Oracle or MS SQL Server as
>> a database server - the key limitation is in the development and
>> administration tools.
>
> Postgresql is much more capable than mySQL, but that capability comes
> with a cost: Postgresql uses process parallelism - it is not
> multithreaded and so uses more per-connection resources than does
> mySQL. Postgresql often needs front-end connection pooling in
> situations where mySQL would not, so even small installations can get
> complicated.
>

Yes, PostgreSQL is certainly a bit more resource-intensive than MySQL
(and forks). And threading, instead of or in combination with multiple
processes, would reduce that overhead a bit. This is especially true, I
believe, if running it on Windows. Other comparative overheads are the
inevitable result of being more capable - a database server that
enforces referential integrity is surely going to be more demanding than
one that doesn't bother with it!

Front-end pooling is often a useful feature even for MySQL - after all,
now that apparently every connection has to use SSL no matter how
unnecessary, making a new TCP/IP socket connection is not insignificant
effort.

> I prefer Postgresql, but YMMV.

So do I. I almost invariably use Python for database code, and
connection pooling is so easy that it's not an issue for me.

Michael S <already5chosen@yahoo.com> wrote:
>
> Back then common wisdom was that Oracle bought Sun Microsystems
> first and foremost because they owned mySQL. Java was a nice bonus
> on top of it. The rest of the company was just an appendage, to
> decide later either useful or not.

From what I remember of the numbers at the time, the ongoing
maintenance revenue from SPARC was enough to justify it. In addition,
Oracle was critically dependent on Java.

This sounds right:
https://www.forbes.com/sites/quora/2015/05/20/how-has-the-sun-acquisition-worked-out-for-oracle/

Andrew.