On 16-Dec-08 22:46, Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>>> 2. How much slower would the whole contraption be? (I'm guessing it 
>>> would make Vista look *fast*...)
> 
>> It would be about 30% faster.
> 
>   If it would indeed by 30% faster, that would only be a sign that the
> current codebase sucks. (Of course being MS, that would hardly surprise
> anyone.)
> 
>   If the codebase sucks, it means the programmers are incompetent. Would
> a change in programming language make them less incompetent?
> 
A couple of possible answers:
- you take it a bit too serious
- not all programmers are equally competent at every level. A good 
programming system and language can result in a better match for every 
team member.
- C does not provide build in error checking, which means that often 
data is checked both in the calling and the called function even if you 
can simply prove that it will comply to the precondition. That might 
give 30% slowing down in some cases. Of course there are also cases wher 
both end fail to check, assuming that it is a task of the other. That 
result in unreliable code.
- A language comes with a paradigm which enables solving problems in 
certain ways. I am doing things in Matlab that I would not do in C 
because although the languages are similar, some things are a few 
keystrokes in Matlab and 20+ lines of code in C. Just as that some 
things are more easy expressed in sql or prolog or with lex/yacc than in 
C and run faster (even if you could do it in C and even if C was used as 
an intermediate step).

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> Just as that some 
> things are more easy expressed in sql or prolog or with lex/yacc than in 
> C and run faster

  That last point I don't buy.

  You can do *anything* with C. You can exactly replicate the machine code
run by SQL or prolog in C. It may be more laborious to do in C than in SQL
or prolog, but it will certainly not run slower.

  If you *don't know how* to make it equally fast in C, that's a completely
different, unrelated issue.

-- 
                                                          - Warp

Post a reply to this message

On 16-Dec-08 23:40, Warp wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> Just as that some 
>> things are more easy expressed in sql or prolog or with lex/yacc than in 
>> C and run faster
> 
>   That last point I don't buy.
> 
>   You can do *anything* with C.

to quote my next line after that '(even if you could do it in C and even 
if C was used as an intermediate step)'. So, yes I am aware that you 
could, but the point is that you wouldn't.
You can implement on the fly garbage collection in C but if your library 
does not support that you simply won't do that when writing e.g. a 
simple TCP stack. In that case you simply allocate a buffer that is 
large enough. And we all know what happens next. If you have a 
language/system that does support that you go for a different solution. 
I am not saying that is as it should be, simply that is like it is.
Another more safe example (as less religious aspects are involved) is 
something like battle chess. There is of course a PC version of it, but 
it would not have come to life if it was not for the blitter in the 
Amiga. There are numerous examples of this kind where the solution space 
for a project is shaped by the available hardware/language/libraries.

Post a reply to this message

Orchid XP v8 wrote:
> Right. So you're telling me that if you wrote an OS and all the 
> associated large-scale applications in a "safe" language, it would be 
> more secure, and run faster (and obviously take drastically less time to 
> develop).

Yes.  Primarily because then you could turn off the memory management, the 
overhead of protection rings, and so on.

> And people still write all OS and application software in C because...??

Legacy.

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>>> 2. How much slower would the whole contraption be? (I'm guessing it 
>>> would make Vista look *fast*...)
> 
>> It would be about 30% faster.
> 
>   If it would indeed by 30% faster, that would only be a sign that the
> current codebase sucks. (Of course being MS, that would hardly surprise
> anyone.)

No. It's the same codebase, one running under the OS doing VMM, address 
mapping, and kernel ring protections, the other running under the OS with 
that turned off. If you actually turn off bounds checking, you get another 
5% speed increase.

But just like staying in the cache gives you good performance, not 
*flushing* that cache every time you (say) allocate a block of memory or get 
an interrupt helps. Not having to do VM map lookups helps a bunch too. The 
numbers and costs of different bits of hardware are all analyzed separately, 
so you can decide if you like having (for example) virtual memory but not 
needing kernel trap protection ring overhead.

You don't get the 30% increase in speed from using a safe language. You get 
the ability to turn off protection from other users from using a safe 
language, which in turn gives you speed. If you want to use AmigaOS, with no 
protection from other users blasting your memory, then you would see about a 
5% performance decrease for the bounds checking.

http://research.microsoft.com/apps/pubs/default.aspx?id=71996
This points to a paper published at ACM SIGPLAN, which of course you'd have 
to pay for, but if you grope around the project you can find it in the 
source code I think. (Unless they took it out since I downloaded it.)

http://channel9.msdn.com/shows/Going+Deep/Singularity-III-Revenge-of-the-SIP/ 
has an extensive interview about "software isolated processes". Check 
starting about 30 minutes in. I'll see if I can dig up the actual URL to the 
paper with the graphs and such in it free, when I next dig out my "old 
stuff" disk.

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.

Post a reply to this message

Warp wrote:
>   You can do *anything* with C. You can exactly replicate the machine code
> run by SQL or prolog in C. It may be more laborious to do in C than in SQL
> or prolog, but it will certainly not run slower.

That's just the Turing completeness argument. :-) It's not always true, tho, 
depending on your underlying CPU architecture. I've used systems where C 
can't be compiled.

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.

Post a reply to this message

Darren New wrote:
> the paper with the graphs and such in it free, when I next dig out my 
> "old stuff" disk.

http://www.google.com/search?q=mspc2006_deconstructingisolation.pdf

I think the paper is probably still in the download, but they've probably 
taken if off their site since it got published in ACM. (You have to turn 
over your copyright to ACM to get published in SIGPLAN.) And sadly the "view 
as HTML" leaves out the charts.

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.

Post a reply to this message

On Tue, 16 Dec 2008 16:46:03 -0500, Warp wrote:

> Would
> a change in programming language make them less incompetent?

Depends on how well they know the language they're switching to, and if 
the problems with their code are syntactical or structural.

Jim

Post a reply to this message

On Tue, 16 Dec 2008 20:48:42 +0000, Orchid XP v8 wrote:

> And people still write all OS and application software in C because...??

Um, they don't?

Jim

Post a reply to this message

Warp wrote:

>   Of because the vast majority of libraries out there you need to write
> something like an OS are written in C.

Ain't that the truth...

>   Also C is conveniently low-level so that you can quite accurately access
> asm and hardware directly.

That's useful for OS construction. I'm not immediately seeing why that 
makes it a good language for writing (say) a web browser.

>   Do languages like Haskell even support inline asm, linking to asm routines,
> or accessing hardware directly (other than with wrappers around existing
> C libraries)?

Inline? No.

But if you write it and assemble it as a seperate object file, it's not 
difficult to link to it. (Takes a 1-line Haskell import declaration.)

Apparently somebody *did* write an OS in Haskell. It was called "House". 
Obviously, like everything to do with Haskell, it was an experimental 
research project which is now long dead...

Post a reply to this message