embryo2 wrote:
The bug issue is very important for the managed vs unmanaged discussion, so Brendan's claim was about an effective almost bug free solution using unmanaged. And one part of the claim was his great personal care for a lot of things including not trusting any hardware. So, when Brendan tells us about the very safe unmanaged solution, which also is due to his personal care, I point to the problem with personal care. And I propose the solution, which requires less personal care. When we see the fact that everybody makes mistakes I think the "more careless" for a programmer solution will prevail.
And here I can see that you have missed Brendan's point entirely. Brendan is not arguing against managed environments
per se (well, he is, but that's actually a side issue to his actual point), but rather that one shouldn't commit to a design feature without knowing ahead of time that it provides a measurable advantage. What he has said time and again is not
this is wrong and always will be wrong, but rather,
where is the advantage in it? All you need to do is go through the numbers and demonstrate that there are advantages to a managed system that cannot be achieved through an unmanaged system - something he would argue that you should have already done anyway before committing to this course of action.
Furthermore,
both of you seem to have missed (or are ignoring)
my main point, which is that you are arguing at cross purposes, and that the reason that is happening is that you haven't agreed on your terminology. I would add that as far as I can tell, no one in this debate - not you, not Brendan, not Sun/Oracle, not Microsoft, not any of those on this hype train for or against - has taken the time to pin down what the terms 'managed code' and 'managed environment'
ACTUALLY MEAN, in a way that is both consistent and which everyone (more or less) can agree upon, meaning that literally none of you know what you are talking about.
Define your damn terms!If you can't, then guess what? That tells me that the terms don't mean
anything. Prove to me that they are something more than marketing, and then we can talk. Better still,
both of you write down on different web pages (or wiki entries or Gists or what have you) what YOU think the terms mean, and what terms are relevant to the conversation, without looking at what the other one wrote for at least 24 hours, then let's see if you two are actually talking about anything like the same things.
embryo2 wrote:
Schol-R-LEA wrote:
facepalm You were the one who brought up benchmarking (unless I missed something), so you should at least know what it is you are asserting before you assert it.
I assert there's no sane comparison between the ARM and Intel.
I agree, and would go so far as to say no such comparison can be made, for a number of reasons, starting with - once again - the lack of any clear idea of what a 'sane comparison' would look like.
There are plenty of reasons why an apples to oranges comparison of the two cannot be made of some aspects of the two designs, no question. That's pretty much true of any two unrelated processor architectures. However, since we don't know just what it is you intend to compare, we can't even say if it is possible or not.
embryo2 wrote:
Have you provided any proof I am wrong?
You do understand that it is the person making a claim who holds the burden of proof, don't you? That's one of the cornerstones of both the scientific method and general engineering.
embryo2 wrote:
Schol-R-LEA wrote:
To be fair, benchmarking seems to be an unfamiliar are for you, so the initial error is understandable. Continuing to defend your lack of knowledge on the basis of an ad hominem argument, however, is simply stubbornness. If you don't have the time or inclination to find out more about the subject, fine, but don't snipe ate Brendan while doing so.
Ok, I can spend a few days and find nothing about sane comparison. What should I do next?
Once again, you have missed my point - you need to understand what a benchmark
is, and what the limitations of benchmarks in general are, in order to interpret them meaningfully. From what you have said, you don't seem to know these things, but are still trying to use benchmarks to support your case (or at least asking for benchmarks that would be relevant to it). You need to perform due diligence before you even can argue that issue effectively.
embryo2 wrote:
Schol-R-LEA wrote:
Intel has put a heroic amount of effort put into squeezing as much performance out of that pile of crap as humanly possible.
In fact it's simpler. Intel just added a translation layer to it's chips. And every freaky instruction now has it's translated representation which is as efficient as ARM can do. But the translation also costs time, silicon and power. Also Intel's processor internal optimization is weak and while it works at the level of 10 instructions, it won't work for larger instruction queue. So, ARM has a really interesting potential to win this game.
First, AFAIK, that has always been true of the x86 processors since the 8086 - they have all used a layer of microcode and/or a translation engine over a simpler (inaccessible but definitely present) load/store hardware implementation.
Second, as I have already said, I agree -
everybody agrees - that the x86 is a shitty design and that ARM (or any of several other designs) would be a better choice. The problem isn't the hardware, it's the software, and the effort it would take to either port the code or develop a software emulator that would perform adequately while supporting a sufficient portion of the existing code base, or some combination of the two. Apple had managed to pull it off during the transition from 68K to PowerPC, and again from PowerPC to x86, but it was rocky, and they only managed it because they had a tight rein on both the hardware and software platforms from the very beginning (and far fewer misbehaving or quirky programs to dispose of).
It is something like a Mexican standoff: for better or worse, Microsoft has been delaying the reckoning they know is coming on this matter, and until they act, the larger PC manufacturers will keep focusing their efforts on cheap PCs regardless of the long-term fallout because that's what their competitors are doing, and the software developers will keep doing things that misuse both the hardware and the OS in non-portable ways because they need an edge over
their competitors. Until one of them changes what they are doing, the other two have to keep at it, too, or risk losing everything.
embryo2 wrote:
Schol-R-LEA wrote:
To get back to the main issue here, a large part of the goal of both Java and .Net was to make it easier to dislodge the industry from Intel's grip.
It's a disputable version. My view is there's just common understanding of the old principle - simpler is better. So, simpler development pays a lot for Java and .Net and Intel here is almost irrelevant.
What I said wasn't opinion, it's a matter of historical record. While they never admitted those goals officially, several developers from both MS and Sun have come forward to say that reducing hardware vendor lock-in was among the (many) design goals of both systems.
embryo2 wrote:
Schol-R-LEA wrote:
Microsoft wanted to be ready to jump to PowerPC or Itanium
Recompilation takes much less efforts than creation of a totally different environment (managed).
What.
/me stares in shock at what Embryo just wrote You're an OS developer. You should know that, managed or otherwise, a lot more goes into porting an OS - even one designed for portability - to a new hardware platform than just recompiling. A
lot more.
Windows wasn't designed with portability in mind, especially after Microsoft killed the support for Alpha and SPARC based servers. If Microsoft put everything else on hold and shifted their entire development staff to porting Windows 10 and all their utilities, development tools, applications, etc., to ARM (or any other platform), it would still take them two or three years of work - and they would have to get every single hardware and software vendor on board with them before they committed to doing it, or it would be the Itanic all over again. While they know that the x86-64 hardware will eventually need to be replaced, they cannot afford to make that jump until the last possible moment. I wish it were otherwise, and so do they, but that's the reality of it.
Yes, shifting to a managed environment would take a comparable effort, I agree, but the advantage of doing so is that it can be done piecemeal, in stages, without having to take an irreversible leap into the unknown. By moving a large part of their development work and that of their clients to .NET, they were trying to amortize the costs of that shift over a period of several years, as well as reduce the risks - if something catastrophic happened to block the hand-over, they would still have the old platform to fall back on for a while, and the effort wouldn't be wasted when they re-targeted to some other new platform. But - and this is the point Brendan is making - they knew from the start that there would be a price to pay for it, and they have fought tooth and nail to get their clients to pay that price.