USB3? Not until the prices hits parity on hardware and the diversity somewhat equals USB2 gear.
I assume by "prices hits[sic] parity on hardware" you're referring to the prices on USB 3 support chips on the motherboard, i.e. you're waiting for machines that support USB 3 to be as cheap as machines that support USB 2, because sanely-designed machines with USB 3 support also support USB 2 peripherals. (They work Just Fine in my Retina MBP, for example; did you somehow find an insanely-designed machine, or did you just assume, incorrectly, that there's no backwards compatibility with USB 3?)
Memory? My current AMD laptop has 6GB upgradeable to 8GB (if someone does 8GB sticks I'd bet it'll go to 16GB - my Dell went to 4GB even though the literature says it tops at 2), I don't have such a hard time believing that Macbooks either short on memory slots or they're already maxed.
My current Retina MBP laptop has 16GB, which is the max.
I fear we're getting too specific from the main topic. The question asks "Is the Rise of Skeuomorphic User Interfaces a Problem?", not "Where did Apple go wrong?". To answer OP's question, I feel it's a tool used both to integrate new users and ease long time users into new paradigms, so I think not.
To answer OP's question, I feel it sometimes is used to fuck up applications (the worst example being Lion's Address Book, whose attempt to emulate a book is an Epic Fail, improved by Mountain Lion bringing back the 3-pane look; iCal didn't skatomorphize the controls, but they did manage to reduce the contrast in the title bar/toolbar, but, hey, "Contrast is the Enemy" appears to have been a bit of a fucking theme in Lion, sigh), so I think that, if not done right, it can be a problem, and there are cases where it was done extremely wrong, such as Address Book, so this isn't just a hypothetical concern.
So, perhaps, in principle it's not a problem, but if it ends up leading too many designers down the part of the garden path heavily coated with natural fertilizer, well....
(And I think the fact that most word processors etc. do not emulate a typewriter is a feature, not a bug.)
This is true, but remember, those that don't want those styles generally know how to change settings to make them go away.
In this case, it's not a "setting" in the sense of "run defaults write to make it go away", and at least one of the solutions, LionBleacher, appears to have bleached out all the color, including useful color. I don't know whether any other "change the title bar" hacks work better in that regard.
I'm making a blatant assumption here, but those who do not know how to change the settings will generally like the imitation styles as compared to the purely-digital look. This was proven by many new users in many GUI's past. Looking too "technical" scares new users away.
The fake leather is new in Lion; have a significant number of new users been afraid of iCal in releases past due to it looking "purely digital" but, now that Lion pretends that either a cow or a nauga died to make the calendar app, new users have no problem with it?
As for "useless areas or designs" such as torn edges or leather borders, this is all about aesthetic. It's doesn't take a scientist to understand that people like things to look appealing. In the same manner a gamer loves his graphics to look as realistic as possible, so does any other user who sees imitation materials on their screen.
So do some users who see imitation materials on their screen. Others think they look appalling rather than appealing.
While the contrast issue doesn't have much to do with this topic, the page swipe most certainly does. I can only account this to Apple's attempt to either maintain interfaces across devices (more of which are touch these days), or to further the use of their "Magic Mouse". While I do find this mouse very useful, page swipes like this are not very intuitive to me on a desktop. Clicking on a bookmark ribbon just seems worse.
And Address Book doesn't appear to support page swipes on Lion, at least, which was a source of immense irritation when I was first confronted with the Shiny New Lion Address Book - I tried dragging the page, as that was the "obvious" idea, and it didn't work (and neither do two-finger swipes, at least).
As for "useless areas or designs" such as torn edges or leather borders, this is all about aesthetic. It's doesn't take a scientist to understand that people like things to look appealing. In the same manner a gamer loves his graphics to look as realistic as possible, so does any other user who sees imitation materials on their screen. Well designed abstract or purely digital layouts can look very nice, but they do not invoke most people's sense of value and worth.
And they also don't invoke most people's sense of "who's the fucking idiot who decided that making iCal look like a type of calendar that most people these days have never used is more important than having enough fucking contrast between text and background, even in the title bar/toolbar?" The only people who are used to that type of calendar are older people who need the contrast the most.
(At least in Mountain Lion they apparently realized that the three-pane view in Address Book is actually useful, and that there's nothing usefully "skeuomorphic" about turning the pages in a book by clicking on a fucking bookmark ribbon.)
I think the problem is how do you come up with attractive designs that don't borrow from the physical world.
As opposed to the problem of coming up with attractive designs that do borrow from the physical world, which is a problem that iCal and Address Book, by virtue of looking like ass in their skeuomorphic versions, don't solve.
The correct term for x86_64 is AMD64, not "Intel 64-bit architecture". AMD developed it, and licenses the patent to Intel.
Yes.
Intel64 is Itanium,
No. IA-64 was Itanium, but that architecture (which I think started out as an HP architecture) is now just called the Itanium architecture. "Intel64" is Intel's name for the 64-bit architecture as originally defined by AMD, modulo some differences and modulo Intel and AMD going their own
and subsequently modified by both parties with different flavors of SSE4.
to which Haiku has NOT been ported.
Haiku was not ported to IA-64/Itanium. It was ported to whatever you want to call the 64-bit x86 architecture (I prefer x86-64, with my second choice being AMD64, although I guess if you want to include Intel's version of SSE4 rather than AMD's version, that's "Intel64").
The zEnterprise 196 (z196) is a workload optimized system, that can scale up (over 52,000 MIPS in a single footprint), scale out (80 configurable cores) and scale within (specialty engines, cryptographic processors, hypervisors) executing in an environmentally friendly footprint....
The zEC12 is designed with improved scalability, performance, security, resiliency, availability, and virtualization. The superscalar design allows the zEC12 to deliver a record level of capacity over the prior System z servers. It is powered by 120 of the world’s most powerful microprocessors running at 5.5 GHz and is capable of executing more than 75,000 millions of instructions per second (MIPS). The zEC12 Model HA1 is estimated to provide up to 50% more total system capacity than the z196 Model M80.
Well, yes, that was my point. The workloads run on mainframes are different than the workloads run on other processors.
Some workloads run on mainframes are different from the workloads run on other systems. A workload using software that only runs on, say, z/OS would be such a workload, as per my comment on IMS.
Other workloads are run on many different types of large systems, whether the processors happen to execute a descendant of the System/360 instruction set and the I/O subsystem happens to run S/3x0-style channel programs or not. DB2 workloads could be such a workload, as per my comment on DB2.
When it comes to SSD's I was talking solid state, which can be attached via FC on the z, but the performance is nowhere near what can be achieved with something like the fusionIO PCIe based adapters.
So how about attaching them to the z with a fusionIO PCIe-based adapter? "Overview of IBM zEnterprise 196 I/O subsystem with focus on new PCI Express infrastructure" says that PCIe adapters can be directly attached. Perhaps there are no z/OS drivers for them, but Linux drivers might exist. You can't directly memory-map PCI devices - special instructions are required - but, at least as I remember from my NetApp days, on Alpha you couldn't necessarily make the same sort of direct references to PCI space that you could on x86, so Linux might provide kernel APIs for accessing PCI space rather than having drivers directly make memory-mapped accesses to registers, so those instructions could be put behind those APIs on the z/Architecture port.
(I.e., in that particular case, it's probably a software issue, not a hardware issue.)
Correct, a MI (million instructions) on the z, isn't equal to a MI on any other platform.
A million instructions on instruction set architecture A isn't equal to a million instructions on instruction set architecture B, for all values of A and B (modulo "A" being "32-bit X" and "B" being "64-bit X", perhaps, or other cases where A and B are variants of the same ISA). There's nothing unique here about S/360 and its descendants.
That said IBM rates their machines in "MIPS", for comparison purposes.
Unless they actually count instructions, they should perhaps call them "zUPS" or something such as that, along the lines of DEC publishing VUPs (VAX Units of Performance) for VAXes.
A P90 is rated at roughly 70 Dhrystone MIPS per (http://www.alternatewars.com/BBOW/Computing/Computing_Power.htm). When I stated they there are roughly the same performance I meant it.
So what benchmark did you run to determine that a Pentium P90 had the same performance as a base z114?
Here are some things that IBMs customers care about, where are the Core i7 Extreme numbers for these?
How many CICS transactions can I process per second? How many IMS updates?
Well, you're unlikely to get numbers for the first of those, given that IBM apparently killed off CICS for Windows and I'm not sure which x86 UN*Xes, if any, got versions of CICS. I'm not sure to what extent TXSeries for Multiplatforms would let you, for example, run CICS on Windows Server or Linux.
As for the second, as far as I know, IBM's never ported IMS to any non-mainframe OS.
How about DB2 transactions?
About 13,000 XML transactions per second in at least one benchmark - but those were Xeons, not Cores (server rather than desktop/laptop processors).
MIPS is only marginally useful in the best of conditions, and even then is only useful as a relative measure between two machines of the same architecture running the same workload.
I rather suspect that "MIPS", these days, doesn't measure the how many millions of instructions a processor executes per second. I don't know what the "MIPS" figures for IBM mainframes count, but the figure everybody's quoting for the Core i7 processor is "Dhrystone MIPS", which, as the Wikipedia article says, is "obtained when the Dhrystone score is divided by 1757 (the number of Dhrystones per second obtained on the VAX 11/780, nominally a 1 MIPS machine". Unless the "MIPS" figure for IBM mainframes represents Dhrystone MIPS, and I rather suspect it doesn't, comparing the IBM mainframes "MIPS" figures with the Dhrystone "MIPS" figure is, as you note, bogus. Comparing zEC12 Dhrystone "MIPS" with Core i7 Dhrystone "MIPS" might be more meaningful, modulo the benchmarking limitations of Dhrystone.
Second, Core i7 servers execute 178 BILLION instructions every second, on average? Seriously? 80 instructions per clock cycle, sustained?
Nope. As per the above, what they do is run Dhrystone, as compiled with some compiler with some particular set of options, about 117,000 times faster than a VAX-11/780 ran Dhrystone, as compiled with some other compiler with some particular set of options. I don't know whether there's any information on how much faster than a VAX-11/780 a zEC12 can run Dhrystone; I would not be surprised to hear that it's somewhere in the 50,000 to 150,000 range.
Modern SSD, FC, ethernet and inifiniband connections on x86 are light years beyond the mainframe.
Are they behind the Fibre Channel, Ethernet, and Infiniband connectors in the zEC12 mainframe? (Presumably by "SSD" you mean something other than "solid state drive", given that a "solid state drive" is a type of secondary storage, not a connector.)
I suspect that the "MIPS" figures for IBM mainframes do not, in fact, represent a count of the number of instructions executed per second, in units of one million instructions. I don't know how the "MIPS" figures are generated, but I suspect they're intended solely to be treated as a relative CPU performance figure for comparing two machines. As such, they probably can't be validly compared to other "MIPS" figures measured in some way different from the way IBM mainframe "MIPS" figures are measured.
The 177,730 MIPS figure is a "Dhrystone MIPS" number; as the Wikipedia article says, "Another common representation of the Dhrystone benchmark is the DMIPS (Dhrystone MIPS) obtained when the Dhrystone score is divided by 1757 (the number of Dhrystones per second obtained on the VAX 11/780, nominally a 1 MIPS machine)." There is no guarantee that Dhrystone "MIPS" numbers correspond at all to IBM "MIPS" numbers.
and 64 bit doesn't automatically take 2x the footprint
Are you referring to instruction density, or to data structure density with 64-bit pointers?
unlike Intel, who still can't get it right.
Actually, that's actually AMD's fault, if you're complaining about the x86-64 architecture (unless you blame Intel for not having done a better job than AMD).
Intel's stuff is also microcoded and implemented as RISC under the covers.
Yup, the whole "translate the "complicated" instructions to microops and schedule and run the microops independently" stuff is also being done in the z196 and, presumably, its zEC12 successors. As IBM zEnterprise 196 microprocessor and cache subsystem (not available for free) says:
In the z196 microprocessor, the traditional System z CISC (RX) pipelines are split into multiple shorter latency reduced-instruction-set computing (RISC)-like execution units, and the complex z/Architecture* instructions are cracked into RISC-like microoperations.
("RX" means "memory-to-register or register-to-memory instructions" - they include loads and stores, but also include memory-to-register arithmetic instructions).
In modern x86 processors (dating back at least as far as the Pentium Pro), most instructions are, as far as I know, directly implemented in hardwired logic (or translated into microops that are directly implemented in hardwired logic).
So, at the fetch/decode/execute level, a Shiny New Core i{3,5,7} and a Shiny New zEC12 are rather similar - directly executing register-to-register ops in one clock tick, carving register-to-memory/memory-to-register instructions into microops and directly executing each microop in, I suspect, one clock tick (modulo waiting for memory in the load or store microops), and executing multiple microops in parallel, out of order, register renaming, blah blah blah. The more complicated instructions might be implemented in Shiny New x86 processors by jumping to microcode (which I suspect is made out of microops in Pentium Pro and later) and in Shiny New z/Architecture processors by a fast trap to millicode (which is z/Architecture code + some special millcode-mode-only instructions - think "PALcode"), but even that's not a huge difference.
I.e., yes, the person to whom you're replying is very mistaken. Current z/Architecture machines (and at least the CMOS S/390's) don't interpret the instruction set in microcode, with the clock rate being the speed at which microinstructions are run, with several microinstructions being required for every instruction; I'd say "the clock rate is the instruction rate", except that the processors are superscalar, so more than one instruction could be processed in a single clock tick.
Actually, the z196 is the microprocessor in the previous generation. An IBM paper on the zEC12 refers to the new microprocessor as the "zEC12 processor chip" or just "the zEC12 chip". As they're not selling it on the open market, there's not much reason to give the processor chip its own name, independent from the name of the systems in which it's being used.
Hmmm, six cores with each running at 1 ghz equals 6 ghz with a 5% overhead makes it 5.7 ghz maximum... IBM Marketing!!!!
And the published information supporting your assumption that the cores are only running at 1GHz, and the 5.7 GHz comes from multiplying the clock rate by the number of cores and subtracting 5% as overhead, rather than each core truly running at 5.7 GHz, is?
No, that's not a correct supposition -- quite the opposite, actually. All processors, including Intel X86, use microcode (or what IBM calls millicode) to a degree.
At least from what I've read about the past few generations of S/3x0 chips, millicode is more like PALcode on the Alpha processor than like traditional microcode, i.e. it's a combination of regular machine code and processor-specific instructions that access specialized registers etc., running in a special processor mode with (presumably) fast entry and exit, support for said processor-specific instructions (which presumably trap in either both "problem state", i.e. user mode, and "supervisor state", i.e. kernel mode), and its own bank of general-purpose registers (part of the "fast entry and exit"). Instructions implemented in millicode trap to millicode routines that implement them.
What IBM called "microcode" rather than "millicode" was implemented using processor-specific instructions completely different from the machine's instruction set (instructions often having fields that directly controlled gates).
(And then there's System/38 and the pre-PowerPC AS/400, where the processor instruction set was a CISC instruction set implemented using microcode, and where the compilers available to customers generated code in an extremely CISCy instruction set that the low levels of the OS translated into machine code and ran. For legal reasons - they didn't want to have to be required to make the low-level OS code available to "plug-compatible manufacturers", i.e. cloners - they not only called the microcode that implemented the processor instruction set "microcode" ("horizontal microcode", as it probably was "fields directly control gates"-style horizontal microcode), they also called the aforementioned low level OS code "microcode" as well, even though it ran from main memory and its instruction set was the instruction set that was actually executed in application code ("vertical microcode"), and had the group working on that code report to a manager in the hardware group. See Frank Soltis's Inside the AS/400.)
IBM knows it well. After all, they invented microcode/millicode in the System/360 in 1965.
"Invented", no; the paper generally considered to have introduced the concept was "Microprogramming and the Design of the Control Circuits in an Electronic Digital Computer", by Maurice Wilkes and J. B. Stringer, from 1953. S/360 may have been the first line of computers to use microcode in most of the processors (S/360 Model 75 was, I think, implemented completely in hardwired logic).
Very cutting edge -- so cutting edge I've got to crack open some engineering manuals to try to figure out what they've done, although they probably need to write those manuals.
The only ones defending Wikileaks are those who believe in the information wants to be free. Sound minds recognize a leak for what it is, information that should not be public.
A leak is information that, in somebody's opinion, namely the opinion of the people keeping the information secret, should not be public. Whether their opinion is informed by anything more than a belief that they'd look bad if somebody found out what they were doing is another matter. In the latter case, sound minds belonging to those being unjustly fucked over by the somebodies in question would probably think that information should be public.
Did you even read the article? Employers don't hire women in Iran, which is closer to the root of the problem. Barring them from school is just applied economics.
The Oil Industry University, which has several campuses across the country, says it will no longer accept female students at all, citing a lack of employer demand. Isfahan University provided a similar rationale for excluding women from its mining engineering degree, claiming 98% of female graduates ended up jobless.
and said nothing about any other universities or fields of study.
Come to think of it, it is probably why the idea of acceptance seems so harsh, considering that the opposing viewpoint is the erasure of religion by those enlightened enough to follow the ACLU, et al.
Slashdot Mirror
USB3? Not until the prices hits parity on hardware and the diversity somewhat equals USB2 gear.
I assume by "prices hits[sic] parity on hardware" you're referring to the prices on USB 3 support chips on the motherboard, i.e. you're waiting for machines that support USB 3 to be as cheap as machines that support USB 2, because sanely-designed machines with USB 3 support also support USB 2 peripherals. (They work Just Fine in my Retina MBP, for example; did you somehow find an insanely-designed machine, or did you just assume, incorrectly, that there's no backwards compatibility with USB 3?)
Memory? My current AMD laptop has 6GB upgradeable to 8GB (if someone does 8GB sticks I'd bet it'll go to 16GB - my Dell went to 4GB even though the literature says it tops at 2), I don't have such a hard time believing that Macbooks either short on memory slots or they're already maxed.
My current Retina MBP laptop has 16GB, which is the max.
I fear we're getting too specific from the main topic. The question asks "Is the Rise of Skeuomorphic User Interfaces a Problem?", not "Where did Apple go wrong?". To answer OP's question, I feel it's a tool used both to integrate new users and ease long time users into new paradigms, so I think not.
To answer OP's question, I feel it sometimes is used to fuck up applications (the worst example being Lion's Address Book, whose attempt to emulate a book is an Epic Fail, improved by Mountain Lion bringing back the 3-pane look; iCal didn't skatomorphize the controls, but they did manage to reduce the contrast in the title bar/toolbar, but, hey, "Contrast is the Enemy" appears to have been a bit of a fucking theme in Lion, sigh), so I think that, if not done right, it can be a problem, and there are cases where it was done extremely wrong, such as Address Book, so this isn't just a hypothetical concern.
So, perhaps, in principle it's not a problem, but if it ends up leading too many designers down the part of the garden path heavily coated with natural fertilizer, well....
(And I think the fact that most word processors etc. do not emulate a typewriter is a feature, not a bug.)
This is true, but remember, those that don't want those styles generally know how to change settings to make them go away.
In this case, it's not a "setting" in the sense of "run defaults write to make it go away", and at least one of the solutions, LionBleacher, appears to have bleached out all the color, including useful color. I don't know whether any other "change the title bar" hacks work better in that regard.
I'm making a blatant assumption here, but those who do not know how to change the settings will generally like the imitation styles as compared to the purely-digital look. This was proven by many new users in many GUI's past. Looking too "technical" scares new users away.
The fake leather is new in Lion; have a significant number of new users been afraid of iCal in releases past due to it looking "purely digital" but, now that Lion pretends that either a cow or a nauga died to make the calendar app, new users have no problem with it?
As for "useless areas or designs" such as torn edges or leather borders, this is all about aesthetic. It's doesn't take a scientist to understand that people like things to look appealing. In the same manner a gamer loves his graphics to look as realistic as possible, so does any other user who sees imitation materials on their screen.
So do some users who see imitation materials on their screen. Others think they look appalling rather than appealing.
While the contrast issue doesn't have much to do with this topic, the page swipe most certainly does. I can only account this to Apple's attempt to either maintain interfaces across devices (more of which are touch these days), or to further the use of their "Magic Mouse". While I do find this mouse very useful, page swipes like this are not very intuitive to me on a desktop. Clicking on a bookmark ribbon just seems worse.
And Address Book doesn't appear to support page swipes on Lion, at least, which was a source of immense irritation when I was first confronted with the Shiny New Lion Address Book - I tried dragging the page, as that was the "obvious" idea, and it didn't work (and neither do two-finger swipes, at least).
As for "useless areas or designs" such as torn edges or leather borders, this is all about aesthetic. It's doesn't take a scientist to understand that people like things to look appealing. In the same manner a gamer loves his graphics to look as realistic as possible, so does any other user who sees imitation materials on their screen. Well designed abstract or purely digital layouts can look very nice, but they do not invoke most people's sense of value and worth.
And they also don't invoke most people's sense of "who's the fucking idiot who decided that making iCal look like a type of calendar that most people these days have never used is more important than having enough fucking contrast between text and background, even in the title bar/toolbar?" The only people who are used to that type of calendar are older people who need the contrast the most.
(At least in Mountain Lion they apparently realized that the three-pane view in Address Book is actually useful, and that there's nothing usefully "skeuomorphic" about turning the pages in a book by clicking on a fucking bookmark ribbon.)
I think the problem is how do you come up with attractive designs that don't borrow from the physical world.
As opposed to the problem of coming up with attractive designs that do borrow from the physical world, which is a problem that iCal and Address Book, by virtue of looking like ass in their skeuomorphic versions, don't solve.
Intel 64 == IA64 == Itanium
IA-64 == Itanium. Intel64 != {IA-64,Itanium}; Intel64 == Intel's flavor of 64-bit x86 as licensed from AMD.
The correct term for x86_64 is AMD64, not "Intel 64-bit architecture". AMD developed it, and licenses the patent to Intel.
Yes.
Intel64 is Itanium,
No. IA-64 was Itanium, but that architecture (which I think started out as an HP architecture) is now just called the Itanium architecture. "Intel64" is Intel's name for the 64-bit architecture as originally defined by AMD, modulo some differences and modulo Intel and AMD going their own and subsequently modified by both parties with different flavors of SSE4.
to which Haiku has NOT been ported.
Haiku was not ported to IA-64/Itanium. It was ported to whatever you want to call the 64-bit x86 architecture (I prefer x86-64, with my second choice being AMD64, although I guess if you want to include Intel's version of SSE4 rather than AMD's version, that's "Intel64").
Where does IBM rate their machine in MIPS?
In the IBM zEnterprise z196 server overview:
and in the IBM zEnterprise EC12 Technical Guide:
for example.
Well, yes, that was my point. The workloads run on mainframes are different than the workloads run on other processors.
Some workloads run on mainframes are different from the workloads run on other systems. A workload using software that only runs on, say, z/OS would be such a workload, as per my comment on IMS.
Other workloads are run on many different types of large systems, whether the processors happen to execute a descendant of the System/360 instruction set and the I/O subsystem happens to run S/3x0-style channel programs or not. DB2 workloads could be such a workload, as per my comment on DB2.
When it comes to SSD's I was talking solid state, which can be attached via FC on the z, but the performance is nowhere near what can be achieved with something like the fusionIO PCIe based adapters.
So how about attaching them to the z with a fusionIO PCIe-based adapter? "Overview of IBM zEnterprise 196 I/O subsystem with focus on new PCI Express infrastructure" says that PCIe adapters can be directly attached. Perhaps there are no z/OS drivers for them, but Linux drivers might exist. You can't directly memory-map PCI devices - special instructions are required - but, at least as I remember from my NetApp days, on Alpha you couldn't necessarily make the same sort of direct references to PCI space that you could on x86, so Linux might provide kernel APIs for accessing PCI space rather than having drivers directly make memory-mapped accesses to registers, so those instructions could be put behind those APIs on the z/Architecture port.
(I.e., in that particular case, it's probably a software issue, not a hardware issue.)
Correct, a MI (million instructions) on the z, isn't equal to a MI on any other platform.
A million instructions on instruction set architecture A isn't equal to a million instructions on instruction set architecture B, for all values of A and B (modulo "A" being "32-bit X" and "B" being "64-bit X", perhaps, or other cases where A and B are variants of the same ISA). There's nothing unique here about S/360 and its descendants.
That said IBM rates their machines in "MIPS", for comparison purposes.
Unless they actually count instructions, they should perhaps call them "zUPS" or something such as that, along the lines of DEC publishing VUPs (VAX Units of Performance) for VAXes.
A P90 is rated at roughly 70 Dhrystone MIPS per (http://www.alternatewars.com/BBOW/Computing/Computing_Power.htm). When I stated they there are roughly the same performance I meant it.
So what benchmark did you run to determine that a Pentium P90 had the same performance as a base z114?
Here are some things that IBMs customers care about, where are the Core i7 Extreme numbers for these?
How many CICS transactions can I process per second? How many IMS updates?
Well, you're unlikely to get numbers for the first of those, given that IBM apparently killed off CICS for Windows and I'm not sure which x86 UN*Xes, if any, got versions of CICS. I'm not sure to what extent TXSeries for Multiplatforms would let you, for example, run CICS on Windows Server or Linux.
As for the second, as far as I know, IBM's never ported IMS to any non-mainframe OS.
How about DB2 transactions?
About 13,000 XML transactions per second in at least one benchmark - but those were Xeons, not Cores (server rather than desktop/laptop processors).
MIPS is only marginally useful in the best of conditions, and even then is only useful as a relative measure between two machines of the same architecture running the same workload.
I rather suspect that "MIPS", these days, doesn't measure the how many millions of instructions a processor executes per second. I don't know what the "MIPS" figures for IBM mainframes count, but the figure everybody's quoting for the Core i7 processor is "Dhrystone MIPS", which, as the Wikipedia article says, is "obtained when the Dhrystone score is divided by 1757 (the number of Dhrystones per second obtained on the VAX 11/780, nominally a 1 MIPS machine". Unless the "MIPS" figure for IBM mainframes represents Dhrystone MIPS, and I rather suspect it doesn't, comparing the IBM mainframes "MIPS" figures with the Dhrystone "MIPS" figure is, as you note, bogus. Comparing zEC12 Dhrystone "MIPS" with Core i7 Dhrystone "MIPS" might be more meaningful, modulo the benchmarking limitations of Dhrystone.
Second, Core i7 servers execute 178 BILLION instructions every second, on average? Seriously? 80 instructions per clock cycle, sustained?
Nope. As per the above, what they do is run Dhrystone, as compiled with some compiler with some particular set of options, about 117,000 times faster than a VAX-11/780 ran Dhrystone, as compiled with some other compiler with some particular set of options. I don't know whether there's any information on how much faster than a VAX-11/780 a zEC12 can run Dhrystone; I would not be surprised to hear that it's somewhere in the 50,000 to 150,000 range.
Modern SSD, FC, ethernet and inifiniband connections on x86 are light years beyond the mainframe.
Are they behind the Fibre Channel, Ethernet, and Infiniband connectors in the zEC12 mainframe? (Presumably by "SSD" you mean something other than "solid state drive", given that a "solid state drive" is a type of secondary storage, not a connector.)
Entry level z114 is indeed 26 mips for $75000.
http://www.tech-news.com/publib/pl2818.html
Which is a joke surely? $400,000 will get you 330 mips, which is erm, surely a mistake???!! It's way way too low:
http://en.wikipedia.org/wiki/Instructions_per_second
Core i7 is 177,730 MIPS at 3.3 Ghz.
I suspect that the "MIPS" figures for IBM mainframes do not, in fact, represent a count of the number of instructions executed per second, in units of one million instructions. I don't know how the "MIPS" figures are generated, but I suspect they're intended solely to be treated as a relative CPU performance figure for comparing two machines. As such, they probably can't be validly compared to other "MIPS" figures measured in some way different from the way IBM mainframe "MIPS" figures are measured.
The 177,730 MIPS figure is a "Dhrystone MIPS" number; as the Wikipedia article says, "Another common representation of the Dhrystone benchmark is the DMIPS (Dhrystone MIPS) obtained when the Dhrystone score is divided by 1757 (the number of Dhrystones per second obtained on the VAX 11/780, nominally a 1 MIPS machine)." There is no guarantee that Dhrystone "MIPS" numbers correspond at all to IBM "MIPS" numbers.
and 64 bit doesn't automatically take 2x the footprint
Are you referring to instruction density, or to data structure density with 64-bit pointers?
unlike Intel, who still can't get it right.
Actually, that's actually AMD's fault, if you're complaining about the x86-64 architecture (unless you blame Intel for not having done a better job than AMD).
Intel's stuff is also microcoded and implemented as RISC under the covers.
Yup, the whole "translate the "complicated" instructions to microops and schedule and run the microops independently" stuff is also being done in the z196 and, presumably, its zEC12 successors. As IBM zEnterprise 196 microprocessor and cache subsystem (not available for free) says:
("RX" means "memory-to-register or register-to-memory instructions" - they include loads and stores, but also include memory-to-register arithmetic instructions).
In modern x86 processors (dating back at least as far as the Pentium Pro), most instructions are, as far as I know, directly implemented in hardwired logic (or translated into microops that are directly implemented in hardwired logic).
So, at the fetch/decode/execute level, a Shiny New Core i{3,5,7} and a Shiny New zEC12 are rather similar - directly executing register-to-register ops in one clock tick, carving register-to-memory/memory-to-register instructions into microops and directly executing each microop in, I suspect, one clock tick (modulo waiting for memory in the load or store microops), and executing multiple microops in parallel, out of order, register renaming, blah blah blah. The more complicated instructions might be implemented in Shiny New x86 processors by jumping to microcode (which I suspect is made out of microops in Pentium Pro and later) and in Shiny New z/Architecture processors by a fast trap to millicode (which is z/Architecture code + some special millcode-mode-only instructions - think "PALcode"), but even that's not a huge difference.
I.e., yes, the person to whom you're replying is very mistaken. Current z/Architecture machines (and at least the CMOS S/390's) don't interpret the instruction set in microcode, with the clock rate being the speed at which microinstructions are run, with several microinstructions being required for every instruction; I'd say "the clock rate is the instruction rate", except that the processors are superscalar, so more than one instruction could be processed in a single clock tick.
https://en.wikipedia.org/wiki/IBM_z196_(microprocessor)
Actually, the z196 is the microprocessor in the previous generation. An IBM paper on the zEC12 refers to the new microprocessor as the "zEC12 processor chip" or just "the zEC12 chip". As they're not selling it on the open market, there's not much reason to give the processor chip its own name, independent from the name of the systems in which it's being used.
Hmmm, six cores with each running at 1 ghz equals 6 ghz with a 5% overhead makes it 5.7 ghz maximum... IBM Marketing!!!!
And the published information supporting your assumption that the cores are only running at 1GHz, and the 5.7 GHz comes from multiplying the clock rate by the number of cores and subtracting 5% as overhead, rather than each core truly running at 5.7 GHz, is?
No, that's not a correct supposition -- quite the opposite, actually. All processors, including Intel X86, use microcode (or what IBM calls millicode) to a degree.
At least from what I've read about the past few generations of S/3x0 chips, millicode is more like PALcode on the Alpha processor than like traditional microcode, i.e. it's a combination of regular machine code and processor-specific instructions that access specialized registers etc., running in a special processor mode with (presumably) fast entry and exit, support for said processor-specific instructions (which presumably trap in either both "problem state", i.e. user mode, and "supervisor state", i.e. kernel mode), and its own bank of general-purpose registers (part of the "fast entry and exit"). Instructions implemented in millicode trap to millicode routines that implement them.
What IBM called "microcode" rather than "millicode" was implemented using processor-specific instructions completely different from the machine's instruction set (instructions often having fields that directly controlled gates).
(And then there's System/38 and the pre-PowerPC AS/400, where the processor instruction set was a CISC instruction set implemented using microcode, and where the compilers available to customers generated code in an extremely CISCy instruction set that the low levels of the OS translated into machine code and ran. For legal reasons - they didn't want to have to be required to make the low-level OS code available to "plug-compatible manufacturers", i.e. cloners - they not only called the microcode that implemented the processor instruction set "microcode" ("horizontal microcode", as it probably was "fields directly control gates"-style horizontal microcode), they also called the aforementioned low level OS code "microcode" as well, even though it ran from main memory and its instruction set was the instruction set that was actually executed in application code ("vertical microcode"), and had the group working on that code report to a manager in the hardware group. See Frank Soltis's Inside the AS/400.)
IBM knows it well. After all, they invented microcode/millicode in the System/360 in 1965.
"Invented", no; the paper generally considered to have introduced the concept was "Microprogramming and the Design of the Control Circuits in an Electronic Digital Computer", by Maurice Wilkes and J. B. Stringer, from 1953. S/360 may have been the first line of computers to use microcode in most of the processors (S/360 Model 75 was, I think, implemented completely in hardwired logic).
Very cutting edge -- so cutting edge I've got to crack open some engineering manuals to try to figure out what they've done, although they probably need to write those manuals.
Well, for the previous generation, there's Volume 56, Issue 1.2 of the IBM Journal of Research and Development has some papers on the z196, but, alas, not for free online. They may publish an issue on the zEC12 at some point.
The only ones defending Wikileaks are those who believe in the information wants to be free. Sound minds recognize a leak for what it is, information that should not be public.
A leak is information that, in somebody's opinion, namely the opinion of the people keeping the information secret, should not be public. Whether their opinion is informed by anything more than a belief that they'd look bad if somebody found out what they were doing is another matter. In the latter case, sound minds belonging to those being unjustly fucked over by the somebodies in question would probably think that information should be public.
"women who have become wage earners"
Did you even read the article? Employers don't hire women in Iran, which is closer to the root of the problem. Barring them from school is just applied economics.
The article that I read says only that
and said nothing about any other universities or fields of study.
Come to think of it, it is probably why the idea of acceptance seems so harsh, considering that the opposing viewpoint is the erasure of religion by those enlightened enough to follow the ACLU, et al.
Anybody truly following the ACLU is hardly an advocate of the complete erasure of religion.
Maybe the Iranian women should do like the U.S. women and protest for the right to vote.
...and have a whole bunch of people asking why they're protesting for a right they already have.