"Given that powerpc chips are still the market dominant server chip"

Thats a fundamental misreading of that wiki article
What it actually says is " For example, IBM's servers based on POWER have the highest revenue marketshare (53.9%) among UNIX servers"

Note - UNIX servers, which are a dying breed. Many more people use a Linux variant (which isn't Unix), while what about all the various flavours of Windows?
A majority share of a declining market, is still a declining share.

Milo

Maybe, but the OP was indicating that because Apple had dropped
it the Power PC is no longer a major used chip - which the posters
above have corrected.


And servers don't get changed willy nilly just because something
newer comes along. Companies can't afford to re write everything
for a new platform.

IBM System 36's were outdated ages ago but were still used by alot
of people in the 80's and 90's and some probably still are.

The CPU used in the PS3 is a PowerPC based processor. In fact the Xenon processor used in the Xbox 360 made use of some of the Cell processor development (wonder what Sony thought of this...).

http://en.wikipedia.org/wiki/Cell_(microprocessor)

Cell (microprocessor) - Wikipedia, the free encyclopedia

Moore's Law talks about the number of transistors in a processor not speed or anything else, and still appears to be valid. The difference is that now transistor counts are increasing through adding cores, GPUs and pulling in things like the memory controller.

Not to mention the A-6E Intruder... which used a repackaged IBM 360 as its main computer (AN/ASQ-133) from 1970* to the end of the 1970s, when it was replaced by the AN/ASQ-155 (IBM System/4 Pi) as part of the TRAM upgrade. However, the latter is simply an "improved 360", so the 360 ran the A-6E from 1970 to its retirement in 1997.



* The year the A-6E began production. The A-6A used the Litton AN/ASQ-61 computer.

GreenKnight

Well, you learn something new every day :O

JSF fan it's completely possible for them to have completely messed it up it all depends on their architecture and their road map. I'm just trying to point out that embedded processors running in a distributed system are a little different to the average IT system that you see in a an office and even the back end stuff.

Thanks Peter we I'd forgotten about Green Hills stuff.

I have no great worries about the power architecture disappearing but I have large worries about the stability and reliability of a large system written in C++. I have worked on such things and they tend to be absolutely riddled with bugs.

It is extremely hard to write code in languages like C++ that is truly correct in all ways. e.g. most programmers effectively assume that they will have infinite memory or infinite disc space. There are a huge combination of ways in which some complex procedure can fail and programmers hardly ever cover them all properly nor can one ever be 100% sure that one has managed to test for them all.

If you have magnificent testing, static analysis and everything is perfect, then you still end up with a huge codebase for which each area is only understood by the people who wrote it. In some reliable area, people spend very little effort so the creators leave, or move and later when it needs an update, new people have to relearn it and now they discover that it's not as well documented or designed as everyone thought. It gets to the point where the existing system is complicated and insufficiently well-known by one person that each update is hard and slow - another risk. Especially horrible is when some major assumption about the design constraints ceases to be true or where one needs to re-architect to add a new capability that was not thought of originally.

Such a lot depends on having wonderful programmers and a management that understands and all of that seems very hard to reproduce to me - spending lots of money guarantees nothing.

Their advantages (over making phones which was my area) are that they can limit the number of hardware types they have to support at one time and that the number of "third party" modules (apps) is going to be limited so the code can be fixed properly and you don't have to trying to keep compatibility with your own old bugs.

Writing code that's truly correct in all ways is extremely hard in any language, particularly a compiled language, since your code may be perfectly correct but the compiler may turn it into machine code that doesn't do what you specified; I've seen bizarre crashes caused by a number of obscure compiler bugs in the past. More commonly, it may be perfectly correct according to the design, yet fail because the design is wrong.

The robust embedded code I've worked with in C/C++ typically allocates memory ahead of time, so it can't later fail due to excessive memory allocation or memory fragmentation. The problem then is that you have to ensure you configured it correctly ('this code will never need more than 64 widget buffers'), which comes back to whether the design is correct.

I have C++ and Java code that's been running 24/7 for years, and the only crashes I can think of were due to buggy third-party libraries, buggy device drivers, and incorrect design. They can happen in any language.

While C++ is more verbose than many, that's true of a complex system written in any language I've ever used, and certainly any that were commonly available when the F-35 was originally designed. In addition, a lot of boilerplate code can be generated from much simpler definitions using code generators that have been thoroughly debugged so millions of lines of that code may be produced by thousands of lines of definitions and scripts.

It's not the first language I'd think of for avionics (we were mostly Ada when I worked in that field in the 90s), but so long as the design and ground rules are sensible I don't see why it would be a bad choice. And if the design isn't sensible you'll fail no matter what language you use.

I suspect one of the big issues is finding people who know how to write Ada code. It was still pretty new when I was working with it, so programmers were eager to learn, but it never really seemed to take off outside its military/avionics niche. There are probably thousands of experienced C++ programmers available for every experienced Ada programmer.

I'd be interested to know how it ended up being a disaster since it seemed a sensible design for that kind of environment even if it was excessively restrictive for general software development. I'll go poke around on f-16.net.

Ada is just too restrictive and slow for complex distributed systems in my opinion and if you think about it with these sort of systems there are going to be instances when you need to either do something in assembler or you need a really efficient compiler which from memory the Ada one was pretty rubbish. Ada 95 was god awful and from memory Ada 83 didn't support threading.

I don't really see a barrier to using C++ for these sorts of projects they just need to be engineered as in using software engineering processes. Looser commercial development practices while great for cranking stuff out or 'prototype' code out quickly won't really cut it, which is why I assume the software component of the project is so long and has been marked as one of the biggest risks to be managed as there is probably a very onerous and long winded design, code, review, test, integration cycle going on.

Saab (on the Gripen E) are working with what they say is a new philosophy that segregates mission systems from flight-critical functions to a greater degree than in the past. They claim that it will result in faster validation and less expensive upgrades.

Also, consider history. Doing stealth in an air-to-air combat platform is much more difficult than stealth for ISR or fixed targets (moving or relocatable ground targets are in between) because of the need to provide SA and minimize radar emissions. You need sensor fusion and EMCON, the two being related.

In 1985 the only way to do this was with a supercomputer that was so large that it had to be time-shared among all the sensors and the CNI apertures, so the F-22 did this with Ada. The F-35 changes languages but uses the same architecture.

Today, you can put the memory and speed of the central supercomputer behind each of the sensors and feed information, not raw signals, back to the central processor. That option was not around when the F-35 started.

From Politico this morning:

Nothing definitive, but nonetheless interesting. Potential for some "interesting" MB staff work in early 2013....

S41

Experts: Canada’s Potential F-35 Cut Would Hurt Mission

...........Better JSF News in Britain

Britain has committed to ordering 48 of the F-35B jump-jet versions in the current 10-year core equipment program, but Jon Thompson, the permanent undersecretary at the Ministry of Defence, told the parliamentary defense committee Dec. 12 that he expected the number of aircraft purchased to “rise over time to more than 100” aircraft.

The first production orders are expected to be placed after the government’s 2015 strategic defense review.

The MoD has taken delivery of two F-35s ordered for test and evaluation purposes and a third aircraft is in production. A fourth aircraft could be ordered next year for evaluation work.

The F-35 will fly first operationally with the Royal Air Force in 2018, followed by the Fleet Air Arm and soon after from new aircraft carriers, which are now in production.

F-136?
 

Engines / LO / ORAC / N-a-B

Dumb question time - when the F136 was defunded, what was the status of the programme, and how much would be required to restart it and get the engine certified? I wonder partly as idle speculation, but also because it seems to me that the programme would benefit from engine competition (much as the F100 / F110 competitions have spurred advances) and that if Dave-B were to be binned, then having a nice payoff for RR / UK Plc in the form of F136 back in play could be a win-win deal for all concerned.

Thoughts pls!

S41

Not going to happen. I wish it would, but chances are zero.

S41,

A quick search got this as of 2011:

(By early 2011) work totaled more than 800 hours of testing on pre-SDD and SDD engines. In early 2010, full afterburning thrust was reached in testing of the first production standard engine

Working in DC, I followed F136 very closely in the late 90s and was in touch with the DoD guys who were pushing hard for it at the time. Basically, there were too many people around who were scarred veterans of the US's 'Great Engine Wars' of the late 70s and early 80s, when they basically bet the farm on the PW100 engine and nearly lost the lot. Reinstating competition from GE resulted in a huge drop in costs and improved performance from P&W. (The USN in particular have shown a very strong preference for GE products ever since). However, as those older guys moved off the plot, their influence waned and more vocal opponents gained the upper hand in the Pentagon.

It's my own view (and as ever happy for anyone to disagree) that the US should have kept the F136 going, not only as competition to keep P&W honest, but also to offer an alternate engine source for international sales of the aircraft. Many potential customers have lucrative and well established deals with GE for engine support work - a P&W engined aircraft is going to be less attractive for them. I also believe (but don't know for certain) that the GE engine had lower temperatures and a better surge margin than the F135 - in large part due to the quite exceptional RR technology in it.

Sadly, despite the F136 having a large UK element in it, the MoD was very slow off the mark in getting behind it. As late as 99, senior UK MoD figures declined to support it at all, even when in the States. RR were speechless.

It seems that the F136, having been funded by Congress for many years against the wishes of the Pentagon, finally succumbed to the wider budget issues with the F-35 programme. In the end even Congress just could not find the money to keep it going. There are some good reports, with figures, available on the US Government's GAO website.

Sadly, I think that it's a goner, unless the F135 engine hits a really BIG problem.

Hope this helps a bit.

Engines

Thanks Gentlemen,

I rely on the wisdom available here to sort the wheat from a lot of chaff in these things.

Engines - I'm appalled but not surprised by this; I'd always understood that the F136 would offer a performance edge, and the NAO / GAO view IIRC was that on balance it was likely to cover the cost of developing it through life. This basically meant that it if the worst case was that you'd probably break-even, then it was obviously worthwhile pursuing. As you say, giving P&W a monopoly on the largest military engine programme going forwards seems like a pretty odd way of incentivising them on price or performance.

A shame!

S41

... or it closes the market to non-US competition?

The other factor in the demise of the F136 (now acknowledged by GE insiders) was economic. The payoff for a competitive engine would be lower unit costs and lower operating costs (as a result of giving both sides a big incentive to fix squawks and extend on-wing life), with total benefit that is directly related to numbers of aircraft built. The speed at which the alternative engine would pay off is related to production rate.

As the final struggle over the F136 neared, it became increasingly clear that the rosy promises of 200+ jets a year by 2016, and a 5000-jet production run, were not anything on which one could hang one's hat. The payback was getting later and smaller but the upfront investment was the same.

Interesting question - what about a CTOL/CV-only engine with a core based on the new 737/A320 engine? Would it be big enough and if so, would it weigh and cost less than the F135 with its oversized LP turbine and shaft?