Hello!

Fujitsu´s roadmap shows 2029 as end of sale and 2034 as end of support
of their SPARC product line.

Do other vendors like Oracle still continue to sell them or is SPARC
dead?

--
kind regards
Marco

In article <ugb5fp$6cdq$2@solani.org>, mm+solani@dorfdsl.de (Marco Moock)
wrote:

> Do other vendors like Oracle still continue to sell them or is SPARC
> dead?

It's on the way out. Oracle laid off their SPARC design team in late 2017
and have not released any new processors since the M8. They still offer
SPARC systems for sale, but I doubt they get many buyers. They claim
there will be support until 2034, the same date as Fujitsu.

<https://www.oracle.com/uk/servers/sparc/>
<https://blogs.oracle.com/oracle-systems/post/an-update-on-oracle-solaris-
and-sparc-infrastructure>
<https://blogs.oracle.com/oracle-systems/post/more-news-about-oracle-solar
is-and-sparc-infrastructure>
<https://blogs.oracle.com/oracle-systems/post/announcing-new-enhancements-
to-sparc-t8-and-m8-servers>

That last link seems to be the latest announcement, from December 2021.

They tried to claim to my employers in 2017-18 that SPARC hardware and
software had a future, but since they could not explain how this would
happen, even in outline, we started phasing out support.

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. That meant that they didn't make lots
of extra money to keep SPARC chip development going, and paying for it
without that presumably didn't seem cost effective.

John

According to John Dallman <jgd@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?

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

In article <ugc1bb$c6q$1@gal.iecc.com>, johnl@taugh.com (John Levine)
wrote:

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

As it turned out, they didn't have anything general-purpose. But the
intention certainly seemed to be to integrate hardware and software and
thereby increase sales. Without that, buying Sun Microsystems would not
have made any sense.

They have added some specialised crypto processors and database search
hardware to their own SPARC chips, but those don't seem to have had much
impact. My employers preferred to keep on writing portable code, rather
than contort their software designs to take advantage of niche hardware.

The fact that Oracle had got rid of their processor design team was not
confidence-inspiring, since it told us this hardware would not have a
long-term future. Oracle insisted that it would, but did not back that up
with anything except executive promises, and a refusal to talk about
technical issues.

John

Marco Moock <mm+solani@dorfdsl.de> schrieb:
> Hello!
>
> Fujitsu´s roadmap shows 2029 as end of sale and 2034 as end of support
> of their SPARC product line.

So, SPARC is effectively end-of-life, MIPS development has also
ceased (according to Wikipedia, its owner now makes RISC-V. Bah.),
POWER is still being developed, but without a broad customer base,
and HP-PA and Alpha were abandoned decades ago.

Sic transit gloria mundi.

In article <ugc3gh$1hrml$1@newsreader4.netcologne.de>,
tkoenig@netcologne.de (Thomas Koenig) wrote:

> So, SPARC is effectively end-of-life, MIPS development has also
> ceased (according to Wikipedia, its owner now makes RISC-V. Bah.),
> POWER is still being developed, but without a broad customer base,
> and HP-PA and Alpha were abandoned decades ago.
>
> Sic transit gloria mundi.

Yup. However, consider how many different minicomputer architectures were
created in the 1960s and 70s, and are now totally dead. There are still
quite a few specialised microprocessor architectures in use for embedded
work, although others have been replaced by ARM and RISC-V.

Just at present, the general-purpose architectures that are alive seem to
be:

Going well: x86-64 and ARM64, which have split the mass market, although
ARM64 has potential to eat away at x86-64's desktop and server markets.

Growing, but not yet fully-established: RISC-V.

In established niches, but not growing out of them: POWER, IBM Z.

On the way out: SPARC, Itanium.

Emulated for legacy code: Various 1960s mainframes, VAX.

Gone: MIPS, PA-RISC, Alpha, 68000.

Forgotten: pretty much everything else.

John

John Levine <johnl@taugh.com> writes:
>According to John Dallman <jgd@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?

ARM has specified TM architecturally, I'm not sure if it is on any silicon yet.

https://developer.arm.com/documentation/102873/latest/The-Arm-Transactional-Memory-Extension

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.

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

On Friday, October 13, 2023 at 10:41:14 PM UTC+3, Scott Lurndal wrote:
> John Levine <jo...@taugh.com> writes:
> >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?
> ARM has specified TM architecturally, I'm not sure if it is on any silicon yet.
>
> https://developer.arm.com/documentation/102873/latest/The-Arm-Transactional-Memory-Extension

Could it be specified for the benefit of owners of architectural license,
without intentions of Arm Inc. to implement it in any their cores?

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.

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.

Well, and also if their B-Tree nodes (with integer keys) were structured
with the integer key values stored consecutively in memory, say:
Node_Int {
u32 p_next;
u32 p_prev;
u32 p_up;
u16 n_keys;
u16 sz_rec;
byte i_depth;
byte pad[15];
u32 keys[N];
byte vals[N][sz_rec];
byte finalpad[M];
};

Where, say:
N=65504/(sz_rec+4)
M=65504-(N*(sz_rec+4))

And not so much:
Node_Gen {
u32 p_next; //00, next node, same depth
u32 p_prev; //04, prior node, same depth
u32 p_up; //08, parent node
u16 n_rec; //0C, number of entries in node
u16 sz_rec; //0E, size of entry
byte i_depth; //10, depth of node in tree
byte pad[15]; //11
byte data_rec[65504]; //data area, holds each entry
};

Where, say, each node holds 65520/sz_rec entries, each of which holds a
combination of primary key and node index (internal nodes) or the
contents of a table row (leaf nodes), with the table layout defined
externally (sz_rec being the combined size of all of the fields in the
table).

AFAIK, the latter sort of structure being more typical in databases.

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

....

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

Michael S <already5chosen@yahoo.com> writes:
>On Friday, October 13, 2023 at 10:41:14=E2=80=AFPM UTC+3, Scott Lurndal wro=
>te:
>> ARM has specified TM architecturally, I'm not sure if it is on any silico=
>n yet.=20
>>=20
>> https://developer.arm.com/documentation/102873/latest/The-Arm-Transaction=
>al-Memory-Extension
>
>Could it be specified for the benefit of owners of architectural license,
>without intentions of Arm Inc. to implement it in any their cores?

My guess is that, when TM was a hot topic, someone at ARM was tasked
with writing a spec for it, and they produced a result. Someone was
also tasked with implementing it, but whatever they produced was found
to be lacking, and either was never integrated into silicon, or was
disabled if it was there.

We have certainly seen Intel struggle with TM (in the form of TSX):
Intel disabled them in client and small server CPUs (after the market
introduction of these CPUs in some cases) thanks to bugs, and AMD
never picking these features up. Strangely, Intel still offers TSX-NI
on their latest and greatest server CPU, the Xeon Platinum 8480+.

Makes me wonder how well TM worked on SPARC.

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

On 10/14/2023 1:57 PM, Anton Ertl wrote:
> Michael S <already5chosen@yahoo.com> writes:
>> On Friday, October 13, 2023 at 10:41:14=E2=80=AFPM UTC+3, Scott Lurndal wro=
>> te:
>>> ARM has specified TM architecturally, I'm not sure if it is on any silico=
>> n yet.=20
>>> =20
>>> https://developer.arm.com/documentation/102873/latest/The-Arm-Transaction=
>> al-Memory-Extension
>>
>> Could it be specified for the benefit of owners of architectural license,
>> without intentions of Arm Inc. to implement it in any their cores?
>
> My guess is that, when TM was a hot topic, someone at ARM was tasked
> with writing a spec for it, and they produced a result. Someone was
> also tasked with implementing it, but whatever they produced was found
> to be lacking, and either was never integrated into silicon, or was
> disabled if it was there.
>
> We have certainly seen Intel struggle with TM (in the form of TSX):
> Intel disabled them in client and small server CPUs (after the market
> introduction of these CPUs in some cases) thanks to bugs, and AMD
> never picking these features up. Strangely, Intel still offers TSX-NI
> on their latest and greatest server CPU, the Xeon Platinum 8480+.
>
> Makes me wonder how well TM worked on SPARC.

Never liked TM, even when it was STM.

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.
>
> 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.
>
> 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.
>
Mostly irrelevant. You are waiting for the comparison values to arrive a lot
more often than you spend performing the comparisons themselves. The
whole B-Tree stuff used to be performed on the disks themselves, leaving
the CPU(s) to do other stuff while the Tree was being searched.
>
> Though, assuming the B-Tree's were structured in an appropriate way,
> things like "packed search" / "packed compare" instructions could be useful.
<
Why do you think this is a job for a CPU ??
>
> 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.
>
>
> Well, and also if their B-Tree nodes (with integer keys) were structured
> with the integer key values stored consecutively in memory, say:
> Node_Int {
> u32 p_next;
> u32 p_prev;
> u32 p_up;
> u16 n_keys;
> u16 sz_rec;
> byte i_depth;
> byte pad[15];
> u32 keys[N];
> byte vals[N][sz_rec];
> byte finalpad[M];
> };
>
> Where, say:
> N=65504/(sz_rec+4)
> M=65504-(N*(sz_rec+4))
>
>
> And not so much:
> Node_Gen {
> u32 p_next; //00, next node, same depth
> u32 p_prev; //04, prior node, same depth
> u32 p_up; //08, parent node
> u16 n_rec; //0C, number of entries in node
> u16 sz_rec; //0E, size of entry
> byte i_depth; //10, depth of node in tree
> byte pad[15]; //11
> byte data_rec[65504]; //data area, holds each entry
> };
>
> Where, say, each node holds 65520/sz_rec entries, each of which holds a
> combination of primary key and node index (internal nodes) or the
> contents of a table row (leaf nodes), with the table layout defined
> externally (sz_rec being the combined size of all of the fields in the
> table).
>
> AFAIK, the latter sort of structure being more typical in databases.
>
>
> 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).
>
>
> ...
> >> --
> >> Regards,
> >> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> >> Please consider the environment before reading this e-mail. https://jl..ly

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

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.

It had seemed like, at 32 or 64K, one tends towards a 98 or 99% hit-rate.

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.

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

Where, seemingly Firefox is a gas that will soon expand to use all
available RAM (until one periodically terminates the whole process tree
and reloads it).

*: Partial reason I invested a lot more effort in BGBCC, which I can
rebuild in a few seconds without totally owning my PC. Nevermind if I
frequently end up spending hours or days on long running Verilator
simulations...

AFAIK, a lot of the servers were using 10K RPM SAS drives and similar.

>>
>> 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.
>>
> Mostly irrelevant. You are waiting for the comparison values to arrive a lot
> more often than you spend performing the comparisons themselves. The
> whole B-Tree stuff used to be performed on the disks themselves, leaving
> the CPU(s) to do other stuff while the Tree was being searched.

?...

I hadn't heard of anything like this; and none of the disk interfaces I
am aware of had presented much of an abstraction beyond that of 512B
sectors and linear block addresses.

RAID was typically multiple HDDs (with hardware error correction, ...),
but still presenting a "linear array of sectors" abstraction.

I am aware that older HDDs typically used C/H/S addressing. Early on,
one needing to set up the drive's values exactly as printed on the drive
or it wouldn't work.

I guess, older still, apparently one had to keep the HDD and controller
matched, as the drives could not be read with a different type of
controller than the one that initialized it (with different controllers
using different recording strategies, etc).

Apparently this was fixed with IDE drives, but AFAIK still existed with
floppy drives (but, with more standardization in terms of the recording
strategies used on floppy disks, since changing any of this would render
the floppies incompatible with those made on a different computer).

Though, admittedly, by the time I was using computers, they were mostly
already using IDE drives; but we still used floppies for a while. There
was also the wonkiness that early CD-ROM drives seemed to use
non-standardized cables and typically plugged into the soundcard rather
than using IDE.

It wasn't until after I was an adult that things moved over to SATA.

When I saw videos of early HDDs, I guess the difference was that they
were a lot bigger (roughly the same footprint as a CD-ROM drive but
twice as tall), and also connected with a pair of ribbon cables (in
addition to the power cable).

Well, and I guess there was some sort of older HDD tech where the HDD
was the size of a washing machine and had a lid that could be opened to
access a stack of platters.

Also saw a video where someone was trying to interface an 8-inch floppy
drive with a newer PC, but then having to deal with issues that
apparently these drives ran on 110VAC-60HZ and used 24V data signals
rather than 5V or 3.3V, ...

I guess someone could maybe get creative and mount one sideways in a
full-tower PC case?...

Dude: "Hey, check out my rig!", *kerchunk*, proceeds to pull out an 8
inch floppy... Then maybe rig up a power-bypass, and voltage leveling
stuff to try to plug it into a USB based floppy controller, maybe so
they could store data on it.

Or, maybe build one using some slightly newer tech, but still use 8-inch
floppies, to make "absurdly large" floppies (if one could achieve
similar recording density to a 3.5" floppy, they could fit significantly
more data on an 8" disk).

Then again, practically, this makes almost about as much sense as trying
to stick digital data onto a vinyl record...

Then again, it seemed like a lot of the Gen Z people gained an interest
in vinyl records; which for me seemed a little odd as this was old tech
even by my standards...

Waves cane, "Back in my day, we had CDs and MP3's!".

>>
>> Though, assuming the B-Tree's were structured in an appropriate way,
>> things like "packed search" / "packed compare" instructions could be useful.
> <
> 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...

It seemed like one would need a mechanism for hopefully moderately
efficient "strncmp()" and similar though...

On Friday, October 13, 2023 at 9:48:34 PM UTC+3, John Dallman wrote:
> In article <ugc1bb$c6q$1...@gal.iecc.com>, jo...@taugh.com (John Levine)
> wrote:
> > > 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?
> As it turned out, they didn't have anything general-purpose. But the
> intention certainly seemed to be to integrate hardware and software and
> thereby increase sales. Without that, buying Sun Microsystems would not
> have made any sense.
>

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.

> They have added some specialised crypto processors and database search
> hardware to their own SPARC chips, but those don't seem to have had much
> impact. My employers preferred to keep on writing portable code, rather
> than contort their software designs to take advantage of niche hardware.
>
> The fact that Oracle had got rid of their processor design team was not
> confidence-inspiring, since it told us this hardware would not have a
> long-term future. Oracle insisted that it would, but did not back that up
> with anything except executive promises, and a refusal to talk about
> technical issues.
>
> John

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.

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

On Friday, October 13, 2023 at 10:13:25 PM UTC+3, John Dallman wrote:
> In article <ugc3gh$1hrml$1...@newsreader4.netcologne.de>,
> tko...@netcologne.de (Thomas Koenig) wrote:
>
> > So, SPARC is effectively end-of-life, MIPS development has also
> > ceased (according to Wikipedia, its owner now makes RISC-V. Bah.),
> > POWER is still being developed, but without a broad customer base,
> > and HP-PA and Alpha were abandoned decades ago.
> >
> > Sic transit gloria mundi.
> Yup. However, consider how many different minicomputer architectures were
> created in the 1960s and 70s, and are now totally dead. There are still
> quite a few specialised microprocessor architectures in use for embedded
> work, although others have been replaced by ARM and RISC-V.
>
> Just at present, the general-purpose architectures that are alive seem to
> be:
>
> Going well: x86-64 and ARM64, which have split the mass market, although
> ARM64 has potential to eat away at x86-64's desktop and server markets.
>
> Growing, but not yet fully-established: RISC-V.
>

Is RISC-V really present in general-purpose computing?

> In established niches, but not growing out of them: POWER, IBM Z.
>

IBM Z has established niche.
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.

> On the way out: SPARC, Itanium.
>
> Emulated for legacy code: Various 1960s mainframes, VAX.

Some people emulate Alpha, too. Not many, I would guess.

>
> Gone: MIPS, PA-RISC, Alpha, 68000.

68K still sold today in form of ColdFire. But those are microcontrollers
rather than general-purpose computers.

>
> Forgotten: pretty much everything else.
>
> John

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.

Of course, companies' ideas of what things are worth can seem very odd.
Around the same time, in 2008, Microsoft offered to buy Yahoo! for $44.6
billion, which seemed like a "take the money and run before they realise
they've overpaid" kind of offer, but Yahoo! rejected it as too low.

John

Michael S <already5chosen@yahoo.com> schrieb:
> On Friday, October 13, 2023 at 10:13:25 PM UTC+3, John Dallman wrote:

>> Gone: MIPS, PA-RISC, Alpha, 68000.
>
> 68K still sold today in form of ColdFire. But those are microcontrollers
> rather than general-purpose computers.

ColdFire does not implement the whole 68000 instruction set
(at least according to Wikipedia), some instructions and some
addressing modes are not implemented.

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:

> We have certainly seen Intel struggle with TM (in the form of TSX):
> Intel disabled them in client and small server CPUs (after the market
> introduction of these CPUs in some cases) thanks to bugs, and AMD
> never picking these features up. Strangely, Intel still offers TSX-NI
> on their latest and greatest server CPU, the Xeon Platinum 8480+.

IBM had it working on POWER8, released a buggy implementation (as
in "freezes the processor") on POWER9, and then dropped support
in Power10.

I haven't seen any benchmarks showing advantages/disadvantages
on POWER8 vs. POWER9.

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.

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.

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 12:48, Thomas Koenig wrote:
> Michael S <already5chosen@yahoo.com> schrieb:
>> On Friday, October 13, 2023 at 10:13:25 PM UTC+3, John Dallman wrote:
>
>>> Gone: MIPS, PA-RISC, Alpha, 68000.
>>
>> 68K still sold today in form of ColdFire. But those are microcontrollers
>> rather than general-purpose computers.
>
> ColdFire does not implement the whole 68000 instruction set
> (at least according to Wikipedia), some instructions and some
> addressing modes are not implemented.

That is correct. It also (depending on the version - there are multiple
ColdFire variants) implements instructions that are not in the 68k ISA.
The idea behind ColdFire was to re-implement the most used parts of the
68k ISA in a fresh design using a RISC-style implementation but keeping
the variable instruction length. The addressing modes dropped were
relatively rarely used, especially on later 68k devices (like 68030 and
68040) where they were slower than using simpler modes despite those
needing multiple instructions.

ColdFire is, however, rarely seen these days, and to my knowledge it has
been many years since any new ColdFire microcontrollers were introduced.

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.

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

John