I don't have to be a great human being to be better than you, snowflake.
I heard Mickey Mouse is a corporate stooge.
The guy must have something to hold over the heads of some media bigshots. I can't see any other reason why the two top Democratic party media properties would pass on giving the Republicans a black eye like this.
C++ wasn't designed, it was accreted.
C++ is to C as Lung Cancer is to Lung.
Something of value was lost, but it was lost a couple of years ago.
Yes. And the problem is that VB is MS only. It is a vendor lock in.
It soon won't be, though. But I reckon waiting for this stuff to show up would be kind of a setback for a four-year college degree.
That's terrible. They should pour it on PETA members.
Simply put, systemd DOES NOT hold up to POSIX scrutiny.
POSIX hasn't bothered to scrutinize it, as stuff such as the init system are outside the scope of POSIX. (SUSv3-compliant systems include a system using launchd, a system using SMS, and some systems that, as far as I know, still use System V-style traditional inits.)
The link in the post above yours provides a good discussion. What you say is correct, it appears as 2 processors. However it does not provide the performance of 2 processors, but has about a 40% increase over 1 processor. This means that neither thread is running at full speed. Much mainframe workload depends on fast uniprocessing, so slowing down a thread by using SMT is not desirable in those situations. Therefore, zOS would have to specifically allow certain jobs to use SMT.
So that, for example, tasks within a job with SMT enabled could be scheduled with two tasks running on the same core as separate threads, rather than running on different cores?
(In the synchronicity department, the quote that popped up on
Congratulations on learning to type. Now, go away and work on coming up with something worth saying.
where exactly would a five mile test loop do some good?
Anywhere it's built, since the purpose of a TEST LOOP is to develop the technology.
Did you really not know this?
Mainframes do have one cool thing going for them that is not respected on smaller machines - portability. There's code that's been in use for several decades on mainframes running in a stack of emulators. Each new mainframe gets an emulator to make it possible to act just like an an old mainframe.
Actually, since System/360, each new IBM mainframe got a CPU that executed an instruction set that was a superset of the previous mainframe's instruction set, just as, for example, an 80486 executed an instruction set that was a superset of the 80386's. They did have to provide a mode bit for, say, 24-bit addressing vs. 31-bit addressing, but that's about it - there's also a difference between 64-bit mode and the 32-bit modes (24-bit addressing and 31-bit addressing), but that's true of just about every 64-bit processor out there except for Alpha (which was born 64-bit).
So there's no need, at the hardware layer, for emulation, other than the mode bits, to run older S/360 user-mode ("problem state") code, and certainly no need for a stack of emulators.
S/360 and earlier S/370's had options to emulate older non-S/3x0 processors, such as the IBM 14xx and 70xx systems; I don't know whether they still provide that with any level of hardware/firmware assist or if that's just done in software (which it can be, these days).
There's also backwards compatibility in the OS, but I doubt that involves multiple layers, just the continuing ability to support older APIs and ABIs on newer versions of the OS. That's not unique to IBM's operating systems, although they might be stricter about it than Microsoft or Sun^WOracle or... are.
The reason that this is the first mainframe with SMT is simple. Prior to the previous generation (z12), most mainframe workload was z/OS, and z/OS has no support for SMT.
Presumably by "support for SMT" you mean "understanding that you don't have n processor cores with their own CPU resources, you have n/T processor cores, each of which can run T streams of code at once sharing some of those resources", so that the scheduler might not treat all entities capable of running streams of code the same.
I don't know whether z13's SMT manifests itself as each core looking like two processors, but I have the impression that other chips that implement T-way SMT look mostly like chips with T times as many cores as they actually have, and could be treated by an SMP-capable OS in that fashion, but that doing so might not be the best way to treat them.