Boxing and Unboxing ??

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I was originally thinking that it might be useless to make one set of languages
completely type safe as long as another set of languages exists that is not type
safe. The authors of malicious code simply would not migrate to the new
technology.

????

The point is to prevent the black hat in exploiting
bugs in the code written by the white hat.

I am not aware of any language that attempts to prevent
black hats from writing malicious code (in the general
context - there are attempts to limit applications
access).

Arne

 

[Barry Kelly]

So if you are rating the quality of my suggestion on the
incorrect basis of credibility rather than the correct basis of validity, you
are rating from an incorrect basis.

I'm not rating the quality of your suggestion at all. In fact, I
explicitly say that I'm not saying it's a bad thing. I'm just giving you
a suggestion, from my own personal opinion - that it's best to be as
well-informed on the subject as possible before suggesting improvements!

-- Barry

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

That does not really eliminate reference counting, it merely delegates it to the
GC.

..NET GC does not use reference counting.

Arne

 

[Peter Olcott]

Maybe.

I doubt that the final truth on language design is written yet.

But C# in current versions are as they are.

Arne

Yes and they are improving all the time.

 

[Peter Olcott]

90 hours work per week and quality code does not get along very well.

Arne

If the absolute prerequisite to all coding is a 100% complete design, then
quality remains optimal.

 

[Barry Kelly]

I don't have time to do it this way.

OK. Let me rephrase it: I think you'll get the information you need
faster by doing it that way, not least because, as the mantra of every
performance expert goes, you need to measure, measure, measure!

It doesn't need to be a whole application, just some basic routines.
Start with the innermost loops; if that's too much, go deeper, if it's
still too much, then simplify. But without measurement, even with all
the questions and answers you get here on the forums, it's essentially
just guessing. I'm discounting algorithmic analysis because I'm sure
it's mostly baked and done already since you've done it before in other
languages.

You might even find out relatively quickly that C# & .NET won't do what
you need. Even then, all isn't lost; you could look at using C++/CLI to
integrate some existing unmanaged C++ code, and still get benefits from
the rest of .NET.

By working 90 hours a week, I am still 80
hours a week short of what I need to get done.

Huh? I'm very sorry that you can't get a better job? How do you expect
people to reply to this - it's not a technical problem!

-- Barry

 

[Barry Kelly]

But if you want to understand the language -> machine instructions
stuff, then maybe C# is not for you.

It is a language designed to abstract that stuff away.

You are not
supposed to care about it.

I strongly disagree especially with this last statement. By Joel's Law
of Leaky Abstractions, I believe it's important to be aware of the
abstractions and assumptions one is basing one's position upon. And the
CPU hasn't gone away: for working with GCHandle / interop with unmanaged
code, for writing correct lock-free code, for getting maximum
performance when it's needed - you need to peer under the covers to get
that info.

-- Barry

 

[Peter Olcott]

OK. Let me rephrase it: I think you'll get the information you need
faster by doing it that way, not least because, as the mantra of every
performance expert goes, you need to measure, measure, measure!

It doesn't need to be a whole application, just some basic routines.
Start with the innermost loops; if that's too much, go deeper, if it's
still too much, then simplify. But without measurement, even with all
the questions and answers you get here on the forums, it's essentially
just guessing. I'm discounting algorithmic analysis because I'm sure
it's mostly baked and done already since you've done it before in other
languages.

You might even find out relatively quickly that C# & .NET won't do what
you need. Even then, all isn't lost; you could look at using C++/CLI to
integrate some existing unmanaged C++ code, and still get benefits from
the rest of .NET.

I need to thoroughly understand all of the means to improve the performance of
C# programs before I invest the time to learn any other aspect of C# or the .NET
architecture. Directly asking questions on this newsgroup has proved to very
efficiently fulfill my requirements.

I am learning the kinds of nuances that are tiny little footnotes in 1,000 page
books, without having the carefully study these 1,000 page books. Trial and
error (as you are suggesting) is an even less efficient approach than carefully
studying these 1,000 page books. Trial and error would have never told me about
the [ref] parameter qualifier, and it was only a tiny little footnote in a 1,000
page book.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I need to thoroughly understand all of the means to improve the performance of
C# programs before I invest the time to learn any other aspect of C# or the .NET
architecture. Directly asking questions on this newsgroup has proved to very
efficiently fulfill my requirements.

I doubt you will understand C# performance just by asking questions
here without actually coding.

When about performance knowing some pieces here and there may
be worse than not knowing anything.

I am learning the kinds of nuances that are tiny little footnotes in 1,000 page
books, without having the carefully study these 1,000 page books. Trial and
error (as you are suggesting) is an even less efficient approach than carefully
studying these 1,000 page books. Trial and error would have never told me about
the [ref] parameter qualifier, and it was only a tiny little footnote in a 1,000
page book.

The point is that there are actually usefull and necessary stuff in
those 1000 pages.

Arne

 

[Peter Olcott]

I'm not rating the quality of your suggestion at all. In fact, I
explicitly say that I'm not saying it's a bad thing. I'm just giving you
a suggestion, from my own personal opinion - that it's best to be as
well-informed on the subject as possible before suggesting improvements!

I am well-informed on the general subject of computer language design. The
ideal computer language design involves reducing programmer effort without
reducing program performance.

Since my suggestion reduces programmer effort, AND increases program
performance, it is therefore an optimal improvement to the current design.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I strongly disagree especially with this last statement. By Joel's Law
of Leaky Abstractions, I believe it's important to be aware of the
abstractions and assumptions one is basing one's position upon. And the
CPU hasn't gone away: for working with GCHandle / interop with unmanaged
code, for writing correct lock-free code, for getting maximum
performance when it's needed - you need to peer under the covers to get
that info.

For interop you obvious need to know something about
the native stuff to use the functionality. That is not
"looking under the hood".

Regarding getting maximum performance then it can
be necessary to look under the hood, but it can also
be dangerous. Often you end up optimizing for current
..NET version on your current PC. Performance characteristics
for the .NET versions and the hardware being used in the
codes life time may be significantly different.

The term "virtual machine" is not popular in the .NET world
due to its Java sound. But you are coding to such a beast.
And MS or whoever provides the .NET runtime for the platform
handles the mapping from that to the real thing.

If the programmer wants to inside his/her head to see the
native instructions for the code being written (as was the
case in the post I commented on), then I don't think
C# is the right choice.

Arne

 

[Peter Olcott]

I doubt you will understand C# performance just by asking questions
here without actually coding.

In my case I understand the performance from understanding the details of the
underlying architecture. If you don't fully understand the underlying
architecture, then you can't fully understand the performance issues. From a
theoretical point of view there is no reason why the .NET architecture needs to
be any slower than straight native code.

With the advent of generics it is now far simpler to very closely match the
performance of straight native code. Eventually the .NET architecture will be
able to exceed native code performance. It will be able to exceed native code
performance by simplifying the process of computer language construction, thus
allowing more time to be spent on creating better compilers.

When about performance knowing some pieces here and there may
be worse than not knowing anything.

I am learning the kinds of nuances that are tiny little footnotes in 1,000
page books, without having the carefully study these 1,000 page books. Trial
and error (as you are suggesting) is an even less efficient approach than
carefully studying these 1,000 page books. Trial and error would have never
told me about the [ref] parameter qualifier, and it was only a tiny little
footnote in a 1,000 page book.

The point is that there are actually usefull and necessary stuff in
those 1000 pages.

Arne

 

[Peter Olcott]

For interop you obvious need to know something about
the native stuff to use the functionality. That is not
"looking under the hood".

Regarding getting maximum performance then it can
be necessary to look under the hood, but it can also
be dangerous. Often you end up optimizing for current
.NET version on your current PC. Performance characteristics
for the .NET versions and the hardware being used in the
codes life time may be significantly different.

The term "virtual machine" is not popular in the .NET world
due to its Java sound. But you are coding to such a beast.
And MS or whoever provides the .NET runtime for the platform
handles the mapping from that to the real thing.

If the programmer wants to inside his/her head to see the
native instructions for the code being written (as was the
case in the post I commented on), then I don't think
C# is the right choice.

Arne

If a C# programmer lacks the ability to see inside his head the underlying
machine code corresponding to the specified C# code, then this programmer lacks
a sufficient understanding of C# and .NET.

For business apps that read and write text to databases, this won't make much of
a difference. To the author of the database management system itself, this makes
a significant difference. The difference is between excellent quality and
mediocrity.

 

[Barry Kelly]

I am well-informed on the general subject of computer language design.

The
ideal computer language design involves reducing programmer effort without
reducing program performance.

I think this definition of 'ideal' is faulty. There are many ideals in
computer languages: imperative languages are not ideal for querying
(that's why we have SQL), nor pattern matching (that's why we have
regular expressions), etc.

"Programmer effort" can only be measured in terms of solving some
problem. Some languages are better at some classes of problems than
others. There is no single ideal.

Also, your statement precludes any reduction in programmer effort if it
reduces program performance. By that logic, we'd all be programming in
assembler. Programming languages are abstractions: they hide details
behind a conceptual framework. In fact, they are abstraction-building
abstractions, and different languages are better suited to different
abstractions, cf. functional languages for functional abstractions,
object oriented, logic languages, etc.

Since my suggestion reduces programmer effort, AND increases program
performance, it is therefore an optimal improvement to the current design.

It also increases language complexity, which can increase programmer
effort.

I'm not strongly opposed to your suggestion at all, BTW. Just want to
make that absolutely clear. I do think I'd hardly ever use it, though -
it's usually better to work with reference types instead, and reserve
value types for value-oriented abstractions, such as complex numbers,
Point, Matrix, int, decimal, that kind of thing.

In fact, I'd be more strongly in favour of explicitly immutable value
types, and let the CLR figure out if a 'const &' calling convention
could be applied, because I think that would more closely reflect
situations when value types are useful (in my experience).

-- Barry

 

[Jon Skeet [C# MVP]]

The systems that I am developing are not business information systems where
something can be 10,000-fold slower than necessary and there is no way for
anyone to notice the difference. In some cases a two-fold difference in the
speed of an elemental operation can noticeably effect response time. I am not
comfortable switching to C# until I know every detail of exactly how to at least
match the performance of native code C++.

But, without evidence, you seem obsessed with boxing and unboxing.
There are many, many, *many* other areas of performance to consider -
why are you so hung up about boxing and unboxing, which almost
certainly *won't* be a significant factor?

 

[Jon Skeet [C# MVP]]

That would seem to be a fine restriction. Now if we can only add an [in]
parameter qualifier that passes all large objects by reference, yet makes them
read-only.

I still don't believe you understand reference types, or what's passed
- either that, or you're considering creating large value types, which
is almost certainly a mistake.

 

[Barry Kelly]

For interop you obvious need to know something about
the native stuff to use the functionality. That is not
"looking under the hood".

I think doing a lot of interop effectively requires a fair amount of
knowledge of what the CLR is doing. In particular, there are some almost
sneaky things the CLR can do, such as the GC collecting your class
before its methods finished executing, that can cause insidious bugs.

There was one which stuck in my memory last year:

http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/msg/6233389a2b0aa149

A bug in Ping which causes access violations. Even examining the C# code
of the Ping class, it's not obvious how it happened. I also wrote a blog
post on the exact mechanics:

http://barrkel.blogspot.com/2006/07/not-so-lazy-garbage-collector.html

Regarding getting maximum performance then it can
be necessary to look under the hood, but it can also
be dangerous. Often you end up optimizing for current
.NET version on your current PC. Performance characteristics
for the .NET versions and the hardware being used in the
codes life time may be significantly different.

Perhaps, but I doubt things like Windows, CPUs and caches / memory
hierarchies are going away anytime soon, and you need to have an idea of
the behaviour of those guys, even if it's simple rules of thumb, like
"row-then-column" rather than "column-then-row" when iterating through
large 2D arrays, or writing asynchronous code to avoid thread-switching
overhead, etc.

The term "virtual machine" is not popular in the .NET world
due to its Java sound. But you are coding to such a beast.
And MS or whoever provides the .NET runtime for the platform
handles the mapping from that to the real thing.

If the programmer wants to inside his/her head to see the
native instructions for the code being written (as was the
case in the post I commented on), then I don't think
C# is the right choice.

Sure, if one is tweaking one's code so it inlines "just so", or adds
comments like:

// not creating variable for this expression because it forces
// register spill to stack

.... then I think one is going to far, I agree.

-- Barry

 

[Peter Olcott]

I think this definition of 'ideal' is faulty. There are many ideals in
computer languages: imperative languages are not ideal for querying
(that's why we have SQL), nor pattern matching (that's why we have
regular expressions), etc.

"Programmer effort" can only be measured in terms of solving some
problem. Some languages are better at some classes of problems than
others. There is no single ideal.

Also, your statement precludes any reduction in programmer effort if it
reduces program performance. By that logic, we'd all be programming in
assembler. Programming languages are abstractions: they hide details
behind a conceptual framework. In fact, they are abstraction-building
abstractions, and different languages are better suited to different
abstractions, cf. functional languages for functional abstractions,
object oriented, logic languages, etc.


It also increases language complexity, which can increase programmer
effort.

It reduces complexity. The programmer would not even need to know what the terms
reference type and value type means much less explicitly distinguish when one is
more appropriate than the other. There would only be two types of parameters;
[out] I want to be able to change it in the function, and [in], I want to make
sure that it won't be changed in the function, and neither one of these ever has
to be passed by value. The underlying CLR can pass by value if it is quicker
than by reference for items of the size of [int] and smaller. The [ref]
parameter qualifier could be discarded.

 

[Peter Olcott]

But, without evidence, you seem obsessed with boxing and unboxing.
There are many, many, *many* other areas of performance to consider -
why are you so hung up about boxing and unboxing, which almost
certainly *won't* be a significant factor?

It is not taking very much effort to completely eliminate all factors
significant and otherwise. Certainly passing large aggregate data types by value
is significant. I want to make sure that I have a 100% understanding on how to
always avoid passing large aggregate data types by value. Boxing and Unboxing
can be comparable to passing a large aggregate data type by value.

Imagine passing an array with millions of elements by value, instead of by
reference. Imagine further still that the only need of this array was to do a
binary search. Now we have a function that is 100,000-fold slower than necessary
simply because the difference between boxing and unboxing was not completely
understood.

 

[Peter Olcott]

That would seem to be a fine restriction. Now if we can only add an [in]
parameter qualifier that passes all large objects by reference, yet makes
them
read-only.

I still don't believe you understand reference types, or what's passed

When I say passed by reference, I mean this term literally, in other words by
memory address. The term in .NET has acquired somewhat of a figure-of-speech
meaning. Literally passing by reference means passing by machine address and
nothing more.