![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 16-Dec-08 22:46, Warp wrote:
> Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
andrel <a_l### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 16-Dec-08 23:40, Warp wrote:
> andrel <a_l### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |