none (none.delete@this.none.com) on April 1, 2021 4:31 am wrote:
> someone (someone.delete@this.somewhere.com) on April 1, 2021 12:21 am wrote:
> [...]
> > https://blogs.saphana.com/2015/06/29/impact-of-haswell-on-hana/
> >
> > ...
> >
> > Third, in S/4HANA we don’t maintain aggregates (totals)
> > any more but calculate them on request on the fly.
> > The “old” predefined aggregates are not so popular
> > any more and the flexibility to aggregate data freely
> > along multiple hierarchies is more important. I know this
> > is against the common practice of the last 50 years
> > in enterprise systems, but it simplifies everything dramatically. The early adopters of S/4HANA all verify
> > this. Since there are no updates of totals anymore, there
> > is no need for database locks (read data for update)
> > and the data entry transactions can now run in parallel with
> > a huge impact on high-volume systems like physical
> > warehouses, order entry systems etc. All what remains are the database inserts, but here HANA has to use
> > an internal lock, when multiple inserts for the same table occur in parallel. Haswell offers now a hardware
> > feature for synchronization (TSX) with which parallel inserts improve up to 5x. I cannot emphasize enough
> > what that means for high-volume transactional systems – it’s a dream.
> >
> > Internal benchmarks are often of limited value to customers and their real world systems, but when you
> > see a 6x improvement for OLTP processing from an Ivy Bridge system (4 sockets) with HANA SP08 to a Haswell
> > system (4 sockets) with HANA SP10, you can only congratulate the engineers of both companies on the
> > work they have done. I can’t wait to see these systems in production at our customer sites or in the
> > cloud. If there was any question about the viability of in-memory database systems, here is the answer.
> > By the way, the pricing looks very attractive, but I have to leave this to the market.
>
> Is there some benchmark not coming from one of the interested parties?
>
> BTW I thought all Haswell had TSX disabled by a microcode patch. Was it not the case for
> Haswell E?

There are only 3 cases:

a) The CPU never attempted to support TSX in the first place (all AMD CPUs, all old Intel CPUs, recent desktop/laptop Intel CPUs).

b) It was proven faulty, a micro-code patch to disable it was released, some people installed the micro-code patch and some didn't, and software has no idea if "CPUID's feature flag says it's supported" means that it can be used safely (because there's no sane way to determine if the relevant micro-code patch was/wasn't installed). This is mostly all Haswell (including Haswell E), and Broadwell and Skylake.

c) It hasn't been proven faulty yet, a micro-code patch to disable it hasn't been released yet, and software has no idea if "CPUID's feature flag says it's supported" means that it can be used safely. This mainly happens because nobody cares about proving it's faulty anymore, partly due to unrelated problems (meltdown, spectre, zombieload, etc) causing an increase in risk aversion among software developers.

- Brendan