Re: hmm..interesting

On Wed, 23 Sep 2009 14:28:29 -0700 (PDT)
Chance Hooper <chance.hooper@xxxxxxxxx> wrote:

Link again, please. I'm struggling to think of a situation where
this could possibly be true.


Well, you've got a discussion of ARM vs Intel architecture here:
*http://arstechnica.com/hardware/news/2008/05/risc-vs-cisc-mobile-
era.ars/2* but also here:
*http://news.zdnet.com/2100-9595_22-343212.html* where they talk about
dual- quad- and eight-core Arm CPUs being underway and all of them
work out at more power per Watt than x86. Not only that, but an
article at *http://www.arm.com/news/18688.html* talks about how "The
CoreSight design kit for the Cortex-A9 processor extends the debug and
trace capability to cover the entire system-on-chip including multiple
ARM processors" - thus the motherboard and architecture designs must
be able to support both multiple cores *and* multiple chips.

So, it's a theoretical thing. The PS3, theoretically, has a huge
amount of computational power. Of course, no real-world software can
take advantage of it. And performance per Watt is not what you
suggested; you just said it was faster. Perhaps, if what you're doing
is parellelisable, and your software takes advantage. So, not MP3
encoding, for example. Measuring real-world performance, rather than
simply the number of MIPS you can squeeze onto a chip is more useful.
And I bet you anything you like that modern x86 CPUs can thrash any ARM
at anything computational or memory-bound.

Admittedly, currently available CPUs are aimed more towards low power
consumption but the fact is that ARM offers either more speed-per-
Watt, or more Flops-per-MHz, from what the architecture discussion
suggests, not to mention the fact that a large amount of the cycles in
x86 are used addressing architecture cludges because x86 has baggage
left over from when the 8086 was around.

No, there's no way any ARM can compete with Intel's offerings for FLOPS
per MHz. For a start, they're not as superscaler, and if you want
double precision (such as many modern applications), modern ARMs aren't
even pipelined.

I was thinking more of Cortex-A9, but, again I am only going by what I
have read

Right, so you're drawing conclusions for a processor that does not
exist in production and based on its marketing material.

- I do know, however, that x86 relies solely on clock cycles
to push compute power,

What you know is wrong. Performance gained from excellent branch
prediction, speculative execution and superscaler design is entirely
independent of clock speed.

as the inherent architecture is really not that
efficient. Even PowerPC was better, although the G5 had cooling
issues, I think that it was a really nice CPU - in terms of outright
power it spanked the P4s and Xeons it was up against

No. PowerPCs have never been as fast as x86 per core or per dollar.
Apple used to pretend this a lot, but all that's been swept under the
carpet now they've seen the light.

- proving again that RISC architecture is the best system,

It's a shame you're not allowing fact into your argument. All modern
x86s are RISC machines. And ARM is rapidly running away from RISC.
(Anybody for variable-length instructions, and travesties such as CLZ,
MULS, and such?)

although x86 is backed by big money

You mean, just like ARM? ARM have stupendous amounts of cash.

- having said that, the proliferation of non-Windows OSes
(OS X, which can run on RISC and x86, as well as Linux, etc)

Again, OS X does not run on any CPU that is not a RISC machine. Apart
from ARM.

in the
mainstream (many netbooks and smartphones run Linux instead of Windows
XP/Vista or Windows Mobile, for example) tends to mean that the x86/
Microsoft axis is nowhere near as dominant as it once was. In fact,
Apple is now the fastest growing seller of Laptops in the world, so
Microsoft doesn't call the shots all the time.

Many things have more than one cause. In the case of Apple, it has
nothing to do with what CPU they have. What it does have a lot to do
with is marketing and bling.

Footprint is only an indicator of long-term storage resource
usage. It has precisely zero to do with performance or memory
consumption.

I know footprint is only an indicator, but I lost the link to the page
I found that had screenshots of the various OSes resource monitors -
basically the point I was trying to make is that any OS that starts
out with 7GB of installed crap and requires a 3GB minimum for its swap
file is not really paying much attention to being efficient - Windows
can bloat because x86 is locked in a MHz race between Intel and AMD
and the x86 has to get faster because the default-choice OS gets less
efficient in each iteration. Better, I feel, to strip things back to
the bone so that you aren't wasting resources and can thus get more
actual work done with less CPU grunt required, because you aren't
wasting half of the system on just, well...running the system. Again,
RISC and a decent OS can do more with less.

Peter explained how this is nonsense better than I have the patience
for.

A shame that other operating systems are vastly more efficient at
using the memory they are given than RISC OS.

As I said before, only because RISCOS effectively stopped any major
development with the death of Acorn.

No, operating systems were making better use of memory than RISC OS a
decade before RISC OS existed.

Most Unix-using engineers tend to run the solver
applications for things like Computational Fluid Dynamics from the
command line to free up as much system space as possible.

No. UNIX users use the command line because the interface is more
efficient, not because it frees more space for the application.
I've never heard such a silly suggestion. The memory consumed by X
and a window manager pales in comparison to the amount of memory
required by complex modelling software.

Ok, you're right in a way, but also I know for a fact that Scentific
and Engineering users are both trying to squeeze every ounce of
compute power out of their system,

And of course, the memory consumed by a GUI doesn't come into
computational power at all. And with any system with a good memory
system designed since the late 70s, neither does RAM usage.

By the way, please don't think I don't know what I'm talking about -

It certainly feels like it.

I was (and probably still am) a member of the SGI developers
conference and was one of a development team that was on such close
terms with Sun, SGI, HP and Windows that we were actually getting the
compilers and libraries changed to suit our needs,

Getting compilers changed to suit your needs (unless it is bug fixes)
demonstrates dreadful software engineering.

so I do know a
little bit about software development, especially cross-platform work
in C and C++. Admittedly, my exposure to RISC OS is minimal, which is
why I came on here in the first place.

Right. Your exposure is clearly to something is clearly minimal. RISC
OS has so many flaws under the bonnet it's impossible to list them all.

I am not trying to boast -
just point out that I am not talking total rubbish when I say that an
OS that takes up 6MB yet offers full multitasking and a nice GUI is
not only an amazing piece of work, but also that it could form the
basis of a great productive OS that would be relevant for today's
market.

Again, size of OS has absolutely nothing to do with performance or
productivity. Zero. Nought. Less than bugger all. There are a huge
number of OSes out there that multitask and have well-thought-out GUIs
that are the size of RISC OS, and smaller. This tells nothing about
their efficiency. And RISC OS is eye-wateringly inefficient. And to
bring it up to modern efficiency standards would make it significantly
larger, as well as breaking most, if not all, current software.

Yes, there are a *lot* of issues with RISC OS, but the
starting point is far better than DOS and Windows 3.1 or OS/2 which is
where we bodge together the current Windows platform(s).

Oh. My. God. Windows and RISC OS have equally turgid foundations.
MOS, anybody? Frankly, I'd favour DOS over MOS any day. Windows's
difference is that they actually provided alternatives for all the
dreadful "grown" API, but kept most of the old stuff for backwards
compatibility.

OS/2 is possibly one of the most elegant GUI desktop OSes of its time.

You could
quadruple the size of the OS and still run it on a very basic machine
far quicker than Vista on a Dual-core PC, because you wouldn't have so
much legacy 8- and -16-bit code floating around or a need to address
architecture that was still fundamentally an upgrade on an 8-Bit 8086
structure, albeit with a lot of extra pipes and bells and whistles.

Again, you show your ignorance. There is no 8 bit code in Windows, nor
has there even been. It has always been 16 bit or greater. 8086 was a
16 bit CPU.

Dear god, man. Visual C++ is more than able to compile well-formed
ANSI C/ISO C89.

I never said it didn't write out ANSI C,

And hardly any C compiler does.

I said it forgives a lot of
errors in compiling as it uses Windows libraries that are designed to
be less critical of memory leaks, etc.

Splutter. So, nothing to do with the language, just its libraries.
Can you provide an example of something where it is less critical of
memory leaks or buffer overflows compared to any of its
contemporaries? No, I thought not.

I speak from bitter experience
when I say that the libraries, compiler and source code that always
failed to port across platforms invariably came from the windows-based
developers.

That's because Windows developers, in general, are clueless and
blinkered. It's possible to write beautiful code in Visual Basic.
It's just that everybody who is capable of doing so uses something
else. This is not a fault in the compiler.

It's great if you're only interested in Windows, or if you
need an IDE that holds your hand and offers code hints (in much the
same way Dreamweaver does for web code),

This "intellisense" is the best usability improvement in software
engineering in decades. How anybody could suggest it leads to a worse
quality of code is beyond me.

but I'd rather see a coder
open up Vi or even Notepad to right a .C or .H file, as it means they
are forced to think about what they are doing.

Sorry, but being forced to thing about minutiae doesn't strike me as a
good way of concentrating on the problem, or the quality of your output.

In a lot of ways you
are right - the hammer doesn't define the carpenter, after all, but a
bad coder can get sloppy habits because they rely on Visual Studio to
auto-correct or suggest code hints, or for the Windows compilers to
take things in their stride - any *nix compiler will be far more
fussy.

Sorry, complete balls. Again, please provide examples of how you can
get Microsoft's compiler to accept invalid source where a UNIX-based
compiler refuses.

As an example, non-fatal memory leaks are usually ignored or
flagged as warnings in Visual Studio - Windows is not as stringent as
Unix in isolating processes, etc. The same code when compiled on SGI,
Sun and HP-UX would flag up many more warnings, then give compiler
errors and fail to compile.

Compilers cannot detect memory leaks.

Don't get me wrong, HP-UX had issues with it's compiler, too - to the
point that we found certain code would simply not compile even though
every other compiler (including Windows and GCC on Linux) would. In
the end, HP altered the compiler, so Microsoft aren't always the
villain of the piece.

HP-UX possibly has the worst C++ compiler of any UNIX, after Sun Studio.
Give me Microsoft's any day.

As for the debugger....well, I guess it's a matter of choice - I
liked SGI's developer tools, but I also like OS X's debugger. Visual
Studio is very user-friendly for beginners, though. I would agree in
saying the debugger was the best part of Visual Studio.

OS X's debugger being gdb, which doesn't have rollback, edit and
restart, or other useful features. (That Visual Studio does have.)

Yes, it's a good start for
students and is great if you're only writing for Windows,

Actually, it's used a lot in the embedded market too; and not just
for targeting Windows CE.

It's also used a lot for Java, although Sun's own IDE and Virtual
Machine are probably better for this.

No, Microsoft's C/C++ compiler has never been used for Java. :)

but for true
multi-platform C development I'd rather use Nedit and either GCC
or native C compilers. That way you end up with truly portable
code

Excuse me while I pick myself up and put my chair upright again. I
can't believe any experienced UNIX software engineer would ever say
this.

Really, why? As someone who earned a living coding on Windows, all
flavours of 64Bit Unix and Linux, I do feel qualified to have an
opinion on this.

Sure, but your opinion is wrong. Unless it means something different
from "software written in vi is more portable than software written in
Visual Studio by the same developer".

Code that compiled on the *nix boxes (aside from GCC
stuff) ALWAYS compiled on Windows.

Cough. I look forward to your NetSurf port to Windows.

Visual Studio code could compile
happily on Windows, yet would crash the *nix compilers with memory
leaks that Visual Studio hadn't picked up.

So, err, you're blaming your compiler crashing on Windows developers?

Someone who can code C in Notepad or
Vi is going to be far more cross-platform useful than a dedicated
Visual Studio person. That's not me talking rubbish

I'm afraid it is. Giving bad developers tools that let them create
rubbish is not the fault of the tools.

As I said before, you're right in as much as a good developer can use
any tool, but bad coding habits are not the fault of the software.
Having said that, I would suggest you walk into any hardcore PHP
developers' meeting and ask how many use Dreamweaver - the same thing
applies: it's a great tool that is very useful for beginners or
designers trying to add code to a site, in the same way that Visual
Studio makes C programming very easy for a beginner to pick up, but
both packages don't focus the mind on the code - they focus the mind
on using the package to generate the code, if that makes sense -
Visual Studio doesn't train the mind in the same way that coding on
Unix with Nedit or even writing Basic on the BBC micro did - maybe,
I'm just getting old!

The number of PHP programmers that can write elegant, robust, secure
code can be counted on the fingers of one hand. (Professional
experience here from running an ISP and consultancy.)

Forget I ever mentioned the idea of a new Risc-based machine and
some actual serious professional development around Risc OS.

Best for everybody, I suspect.

B.

As I showed with the links above, ARM are building faster CPUs that
can match x86 for performance and which appear to support multiple
CPUs .

No, you've shown marketing material. This reminds me fondly of the
time ARM said they got more dhrystones than any other CPU in its
class. Of course, they skirted around the issue that they tweaked
their compiler to spot the benchmark.

Do not believe marketing material, especially for products that do not
exist.

At that point, it all becomes about the motherboard design and
the software - a far simpler task, in reality. Still, if no-one likes
the idea, fair enough.

These days, designing ARM-based motherboards is very almost as complex
as designing x86 motherboards. Again, I speak from professional
experience.

In summary: Modern ARM as is RISC as modern x86. Microsoft's C
compilers are just as good at detecting errors and shunning bad code as
anybody else's, saying that writing code in vi makes for more portable
code than writing it in VS is astonishingly wrong, and the idea that
code from UNIX compiles fine under Windows but the inverse is not true
is simply false.

Oh, and the size of RISC OS has about as much relationship to its
performance or suitability for any task beyond running RISC OS as my
liking pasta is connected to my house being made of bricks.

B.

B.

.

Relevant Pages

  • Re: tee pc
    ... Windows CE on an ARM 926 processor. ... Could it be made to run RISC OS? ... is willing to invest considerable time to write drivers ...
    (comp.sys.acorn.hardware)
  • Re: Is delphi a good introduction to programming?
    ... > A 48KB platform won't even run a win32 implementation, ... > I don't think I'd want to run Windows 2000 on it, ... 68030+FPU doubled compiler performance, and a 68040/33 even was another 50% ... While that is a 206 MHz ARM, ARMs aren't as efficient per clock ...
    (comp.lang.pascal.delphi.misc)
  • Re: Developing BBC BASIC
    ... even if we find somebody able and willing to bring ARM ... BBC BASIC up to the level of BBC BASIC for Windows, ... extremely unhelpful to the RISC OS platform? ... long-term future, I'm afraid it won't be on RISC OS! ...
    (comp.sys.acorn.programmer)
  • Re: tee pc
    ... druck wrote: ... runs Windows CE on an ARM 926 processor. ... Could it be made to run RISC OS? ... Any ARM based machine could be made to run RISC OS given enough ...
    (comp.sys.acorn.hardware)
  • Re: copying c struct from arm to windows
    ... I copied the struct to a shared memory and then copyied it to ... in windows host code: ... The offset of struct A is 2 bytes diffrence from arm. ... [There are probably compiler options to make it do the slicing & dicing, but they might give you problems. ...
    (comp.sys.arm)
Loading