Re: hmm..interesting


Why are you quoting somebody's signature, and a folded quote in reply
to a message that is not the message you are replying to? Is your
client broken, or are you copy-and-pasting into the wrong window?


I'm posting via Googlemail on a PC, so most likely it's broken
somehow...


I know people have belittled the idea of an ARM-based deskside
workstation, but the fact is that at 2GHz, the ARMs outperforms an x86
chip of similar clock speed, according to the article I originally
linked to.

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.

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.

As far as multiprocessor awareness is concerned, I don't
know what ARMs chips are/aren't capable of (or might be in future),
which is why I asked them for some information. Having said that,
almost every other aspect of the concept I had thought might be
workable is being used in the newly annoucned SGI Octane III, albeit
using x86 cpus.

I'm not aware of any ARM product that is multi-processor aware. The
only system I can think of that is is the Hydra.

Multi-core, however, there have been two approaches: two CPUs sharing
the same bus (and thus it is unsafe to run multithreaded code across
them, as there is no cache synchronisation). The other is ARM's
MPCore-related stuff. There has been some ARM11 devices with MPCore,
but I have seen no information about their performance. A9 is also
apparently available with MPCore, but I don't believe any silicon
exists in order see any performance benefit.

Incidentally, A8 is eye-wateringly slow at double-precision floating
point compared to ARM11: not everything gets faster with each edition.

I was thinking more of Cortex-A9, but, again I am only going by what I
have read - I do know, however, that x86 relies solely on clock cycles
to push compute power, 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 - proving again
that RISC architecture is the best system, although x86 is backed by
big money - having said that, the proliferation of non-Windows OSes
(OS X, which can run on RISC and x86, as well as Linux, etc) 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.

(Its VFP unit has been replaced with a "VFP Lite" unit that is not
pipelined, as the VFP, like FPA10, has been depricated. Its
replacement, NEON, doesn't support double precision.)

As for the reason behind trying to get Risc OS to run this system, I
think people took the wrong end of the stick when I spoke about OS
size - that was simply an indicator of how resource-hungry certain
OSes are

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.


And, given you have a certain attention to detail to your use of
English, why not apply the same attention to detail to trademarks and
nouns? It's RISC OS. (We'll let you off for your attention to detail
for realism and technical matters for now :)

I know that drives are cheap and RAM is plentiful, but the fact is
that I'd rather have as much of my system
resource free to run my applications, not end up with a slow system
because the OS and other clutter decide that 50% resource usage is
fine.

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. Yes, I know updates have been
made, but it's all hobbyist scale and the hardware stagnated and
became pottering-about-in-the-shed scale, whereas I was talking about
a venture where you'd have say 50 fulltime developers on the project
and the same again in designing the hardware layout - I doubt that
Castle, or an of the other torch-bearers could rustle up that level of
resource on a permanent basis.

I don't mean that in a derogatory manner - given the scale of things,
it's amazing that what has been achieved was managed with any degree
of success, but I was thinking more about a genuine full-scale start-
up in order to produce a UK-based high-performance workstation that
could be flexible and efficient (both in its operation and its power
consumption/performance ratio).


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, but also don't want to wade through
inefficient User Interfaces just for the sake of being able to click a
button. Given the way the Windows GUI system bloats and the extraneous
crap that gets run, its little wonder that most either try to stick to
*nix in some form, or run things form the command prompt.

By the way, please don't think I don't know what I'm talking about -
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, 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. 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. 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). 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.


As for the person who claimed Visual Studio the greatest thing ever,
I used to be a professional software developer on both Unix/Linux (all
flavours) and Windows (writing CFD and Valve-train dynamics software,
if you wish to know) and the simple fact is that 90% of code written
in Visual Studio failed to compile on other platforms because
Microsoft mess around so much with their compilers, the libraries and
the fact that Visual Studio allows you to get away with fairly sloppy
code (in the same way that a decent web developer doesn't use
Dreamweaver because it bloats code).

Dear god, man. Visual C++ is more than able to compile well-formed
ANSI C/ISO C89. If its users use a load of Microsoft-specific
extensions, that is the lookout of the developer, not the tool. (It's
difficult to find a C compiler that *doesn't* have vendor-specific
extensions. Including ARM's and Acorn's.)

As for sloppy code, either it's valid C or it's not. A compiler is not
there to give you an artistic critical analysis. Please provide an
example of "sloppy code" that Microsoft's C compiler is happy with but,
say, GCC is not. And making use of library or compiler extensions is
not sloppy. Invalid C is in this situation.

Visual Studio does however have by far and away the best debugger that
is bundled with a development suite.

I never said it didn't write out ANSI C, 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. 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. 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), 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. 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. 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.

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.

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.


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.


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. Code that compiled on the *nix boxes (aside from GCC
stuff) ALWAYS compiled on 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.


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!


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 . 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.
.

Loading