Re: hmm..interesting

On Wed, 23 Sep 2009 06:00:55 -0700 (PDT)
Chance Hooper <chance.hooper@xxxxxxxxx> wrote:

--
Graeme Wall

My genealogy website <www.greywall.demon.co.uk/genealogy/>- Hide
quoted text -

- Show quoted text -

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

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

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

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.

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.

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.

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.

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.

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.

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

Relevant Pages

  • Re: Difference between VC++ and UNIX
    ... It uses whatever compiler you have, in whatever language you like. ... like edit Lisp or integrate 3rd party compilers into Visual Studio. ... Windows, HP-UX, and Linux. ...
    (comp.programming)
  • Re: hmm..interesting
    ... work out at more power per Watt than x86. ... mainstream (many netbooks and smartphones run Linux instead of Windows ... the fact that Visual Studio allows you to get away with fairly sloppy ... difficult to find a C compiler that *doesn't* have vendor-specific ...
    (comp.sys.acorn.hardware)
  • Re: Difference between VC++ and UNIX
    ... It uses whatever compiler you have, in whatever language you like. ... like edit Lisp or integrate 3rd party compilers into Visual Studio. ... Windows, HP-UX, and Linux. ...
    (comp.programming)
  • Re: fortran 2003 compiler
    ... Fujitsu for Windows are in maintenance mode. ... I would bet against a Lahey/Fujitsu Fortran 2003 compiler on any ... None of the gfortran developers are interested enough in Windows to ... I'd be willing to pitch in some money to pay a developer. ...
    (comp.lang.fortran)
  • Re: fortran 2003 compiler
    ... Fujitsu for Windows are in maintenance mode. ... I would bet against a Lahey/Fujitsu Fortran 2003 compiler on any ... Nor do I see instructions on the Gfortran wiki on how to ... I'd be willing to pitch in some money to pay a developer. ...
    (comp.lang.fortran)
Loading