code snippet

[Rui Maciel]

So what? If this is a product to be sold/used in thousands and millions,
you'll probably find that a small number of platforms will dominate. Then
it's worth producing a custom version for the top one or two. The rest can
use the slow version.

I don't believe that the idea of replacing C with assembly, in this context,
meant that the assembly instructions represented specialized routines for a
specific platform. In this context, replacing C with assembly meant
replacing C with assembly, in the sense that the routine consisted of a
single specialized piece of code which could only run on a very specific
platform and that there wasn't any alternative to it.

You're assuming this is for a one-off program that will only be run once.
Then you could well spend more time programming than will be saved in
runtime. But usually that is not the case.

Not necessarily. Nowadays compilers do churn out optimized code, and
chances are they do a far better job at it than any random programmer. This
means that, just by tweaking a single compiler flag, we may get all the
optimizations which any random programmer might be able to use, without
wasting days rewriting stuff and while avoiding to increase the complexity
of our project. And there's of course the risk of potentially introducing
new non-trivial bugs which aren't easily catched, even with a debugger.


Rui Maciel

 

[88888 Dihedral]

I don't believe that the idea of replacing C with assembly, in this context,
meant that the assembly instructions represented specialized routines for a
specific platform. In this context, replacing C with assembly meant
replacing C with assembly, in the sense that the routine consisted of a
single specialized piece of code which could only run on a very specific
platform and that there wasn't any alternative to it.

Of course this in not for low novices in C.

Not necessarily. Nowadays compilers do churn out optimized code, and
chances are they do a far better job at it than any random programmer. This
means that, just by tweaking a single compiler flag, we may get all the
optimizations which any random programmer might be able to use, without
wasting days rewriting stuff and while avoiding to increase the complexity
of our project. And there's of course the risk of potentially introducing
new non-trivial bugs which aren't easily catched, even with a debugger.


Rui Maciel

I suggest you should use VB for happy programming
or some other high level languages, please google for books about C
and mixed assembly programming.

 

[Ben Bacarisse]

Do you consider to convert 5 to 10 lines of C to assembly?

No, why do you ask? Would you?

 

[88888 Dihedral]

No, why do you ask? Would you?

I did that 20 years ago on X86 cpu.

It was a piece of cake to gain the 20-40% speed required if paid well.

 

[Seebs]

I did that 20 years ago on X86 cpu.

It was a piece of cake to gain the 20-40% speed required if paid well.

Yeah, uhm. Since then, CPUs have gotten a lot more complicated and
compilers a lot smarter.

Simple question for you: On a modern x86 (say, a Core i5), do you believe
the actual computations are executing the instructions generated from
assembly?

Hint: The answer is "no", and has been for a long time. Nowadays, an x86
CPU consists of a nice modern core with lots of registers which is running
a runtime translator from x86 machine code.

It used to be instruction scheduling was something humans could do pretty
well, and compilers mostly didn't try to do because it wasn't possible to
do it with the resources available. Now it's something humans suck at
and compilers mostly do.

-s

 

[Seebs]

I use about 20 to 26 instructions only in those various kinds of
cpus I played with.

That gives you another significant disadvantage compared to the compiler.

If the compiler is smarter than a professional programmer,
then a lot novice programmers should be fired for not producing
smart and fast programs.

"Smarter" is a pretty broad term.

Of course I check those instructions that preserve the flags also
those control flow instructions with the most likely first in my assembly.

The compiler can consider more possible sequences of instructions per second
than you can per month. The compiler also has the option of using
instructions that don't preserve flags, and thus gaining advantages from
using the flags as intended, and can avoid flow control when it's the
wrong choice.

Dunno if you saw this, but a while back, someone had some PRNG code here,
which included a snippet roughly to the effect of:

if (z)
x += y;

Replacing this with:
x += (y * z);

dramatically improved the efficiency of the entire PRNG, because that branch
had been slowing it down more than any five or ten other instructions.

You are doubtless better at some *kinds* of thinking than a compiler, but you
generally won't beat a modern compiler by enough to notice, and indeed, my
experience has been that people who think they can beat compilers normally
lose to compilers. The only people I've seen beat modern compilers are people
who understand why they normally can't.

-s

 

[88888 Dihedral]

Yeah, uhm. Since then, CPUs have gotten a lot more complicated and
compilers a lot smarter.

Simple question for you: On a modern x86 (say, a Core i5), do you believe
the actual computations are executing the instructions generated from
assembly?

Hint: The answer is "no", and has been for a long time. Nowadays, an x86
CPU consists of a nice modern core with lots of registers which is running
a runtime translator from x86 machine code.

It used to be instruction scheduling was something humans could do pretty
well, and compilers mostly didn't try to do because it wasn't possible to
do it with the resources available. Now it's something humans suck at
and compilers mostly do.

-s
--

I use about 20 to 26 instructions only in those various kinds of
cpus I played with.

Of course I check those instructions that preserve the flags also
those control flow instructions with the most likely first in my assembly.

If the compiler is smarter than a professional programmer,
then a lot novice programmers should be fired for not producing
smart and fast programs.

 

[88888 Dihedral]

That gives you another significant disadvantage compared to the compiler.


"Smarter" is a pretty broad term.


The compiler can consider more possible sequences of instructions per second
than you can per month. The compiler also has the option of using
instructions that don't preserve flags, and thus gaining advantages from
using the flags as intended, and can avoid flow control when it's the
wrong choice.

Dunno if you saw this, but a while back, someone had some PRNG code here,
which included a snippet roughly to the effect of:

if (z)
x += y;

Replacing this with:
x += (y * z);

dramatically improved the efficiency of the entire PRNG, because that branch
had been slowing it down more than any five or ten other instructions.

You are doubtless better at some *kinds* of thinking than a compiler, but you
generally won't beat a modern compiler by enough to notice, and indeed, my
experience has been that people who think they can beat compilers normally
lose to compilers. The only people I've seen beat modern compilers are people
who understand why they normally can't.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / (e-mail address removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

OK, you are selling compilers. I am working on compilers in GCC and MINI C
PORTABLE C and device C!

If you are selling arm compilers, then I agree with you.

 

[Seebs]

Thanks for you appreciations. I am really bad of lousy programmers.

Oh, don't be so hard on yourself. I think you're about average for a lousy
programmer.

-s

 

[Seebs]

The O(1) search of a descent hash can beat all binary search implementations
in speed.

Quite possibly, but it also has more overhead, and for some sizes of lists,
computing the hash is more expensive than the entire search anyway.

Sorry that there's no hash or dictionary built in C as
Python or Perl. That is why we have to do these discussions.

Not really, no. We talk about how to do stuff because people who are
new to C don't know yet.

-s

 

[Seebs]

OK, you are selling compilers.

No, I'm not.

I am working on compilers in GCC and MINI C
PORTABLE C and device C!

That's terrifying.

If you are selling arm compilers, then I agree with you.

I'm not selling compilers at all. I'm merely aware that people who think
they are smarter than the compiler are nearly always wrong. Especially given
your track record of suggestions for things that you think would produce
performance improvements.

-s

 

[Seebs]

is "Various Sound Technical Reasons" a trademark? ;-)

Probably. It's sort of like historical reasons, only slightly more
justifiable.

There's an idiom where capitalizing terms makes them look like proper nouns,
invoking the suggestion that they are references to specific well-known things
which could be described by those words. "Various Sound Technical Reasons"
means roughly the same thing as "there were a series of discussions and
proposed alternatives all of which were considered but shot down because of
perfectly good technical arguments which are too long to go into here, and
we've all had experiences like that where at the end of three months of design
discussions all you really remember is that there were sound technical reasons
none of which are easy to articulate."

-s

 

[88888 Dihedral]

No, I'm not.


That's terrifying.


I'm not selling compilers at all. I'm merely aware that people who think
they are smarter than the compiler are nearly always wrong. Especially given
your track record of suggestions for things that you think would produce
performance improvements.

Thanks for you appreciations. I am really bad of lousy programmers.

 

[88888 Dihedral]

The O(1) search of a descent hash can beat all binary search implementations
in speed. Sorry that there's no hash or dictionary built in C as
Python or Perl. That is why we have to do these discussions.

 

[Bill Reid]

I think there's an operating theory he's a troll, so his
goals are to develop responses to silly questions...
Maybe you should just manually type your data into a
calculator...

    Does it sound like I want a parser using line numbers for the data.

1 12.35 122011
2 11.75 122111

So if I wanted to pull certain data like the 2nd column numbers 1 throughn
an unsigned int number variable would be what was needed. Pass all that data
to a parameter of a function.

If you had just typed all this super-important data into a
calculator eight years ago when you started asking all these
questions about programming some type of market analysis software
in "C", you'd have all the answers you're looking for already...but
it doesn't seem likely you're really looking for answers...

In any event, I would just like to point out (pointlessly) that
several of the development packages I have (most of which were
completely free) have statistical functions, BUT, they usually
operate on arrays of double or sometimes "list" objects in
C++ or whatnot, so since I already had coded various statistical
functions I modified them to work on an array of structures
by using a "step" parameter along with the pointer to the double
data I want to analyze in the first structure of the array.

Now, does that answer all your questions, or what? I'm
sure it doesn't, because why do you feel the need to put
line numbers in your file when they'll be counted by any
"parser" program anyway? (Of course, you would be using
something like fgets() and sscanf() to extract the data
into an array of structures, riiiiiiiight?)

I could just post the pretty simple code right here if
you'd think it would help...but it won't, will it? (I've
already done so in the past, but the people who know the
return value of main() jumped all over it for the usual
bogus reasons.)

 

[Hans Vlems]

No, I'm not.


That's terrifying.


I'm not selling compilers at all.  I'm merely aware that people who think
they are smarter than the compiler are nearly always wrong.  Especiallygiven
your track record of suggestions for things that you think would produce
performance improvements.

Given the complexity and design of modern cpu's, the concept of an
assembler no longer exists.
A program written in what we think of as assembly language statements
in fact gets compiled.
No way a human can come close to the optimization a compiler, for say
an Itanium cpu, will do just
to make the code run...
Hans

 

[88888 Dihedral]

Oh, don't be so hard on yourself. I think you're about average for a lousy
programmer.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / (e-mail address removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Thus the problem of an array of a size around billion or even more items.

Then the binary search is still feasible.

But a hash might not be feasible directly.

 

[BartC]

Given the complexity and design of modern cpu's, the concept of an
assembler no longer exists.
A program written in what we think of as assembly language statements
in fact gets compiled.

By what? Into what? Please give some examples of common CPUs where that is
the case.

The few C compilers that I've used, all for x86, still seem to output code
that looks remarkably similar to x86 assembly. The binary output, when
disassembled, also looks like x86 assembly.

If you're saying that it all gets translated inside a CPU, then perhaps
you're right, but so what? Who cares how the chip implements things; and
anyway that's been the case for a long time. Unless the compiler gets to
generate actual microcode, or to directly program an internal Risc core,
then it's constrained by the documented instruction set just as an assembly
programmer is.

(Compilers supplied by the chip manufacturers might well have access to
internal workings denied to others, which is a bit of a cheat, but how many
people use those?)

Anyway the secret to using assembly these days is to know when it makes
sense to use it. For most of a typical application, it would be crazy to use
assembly (in fact it would be crazy to use C if it's mostly user interface
stuff or just loads of scripting).

But sometimes some things can't be expressed in a higher level language, or
you have some knowledge that is not available to the compiler (or perhaps
you're implementing a language!) then some assembly won't hurt.

No way a human can come close to the optimization a compiler, for say
an Itanium cpu, will do just
to make the code run...

(You make them almost sound like they can do magic. It's been nearly a
decade since the I last created an x86 compiler. The code it produced *was*
generally terrible. Recently testing some (floating point) benchmark or
other against gcc, my compiler took some 2.5 seconds against gcc's 0.7
seconds with full optimisation.

But I'd made sure use my language had a very nice inline assembler; a minute
or two writing some ten lines of assembler to replace the inner loop, and my
timing was 0.6 seconds!)

 

[Rui Maciel]

i claim that the above is false if the code generated is not easy
scalable, not easy comprensible by humans
i'm sorry, but compilers not has to write algoritms for you
you have to write algoritms and the compiler has to traslate them
litterally

My assertion wasn't based on the idea that compilers have to write
algorithms. My assertion is that, given any algorithm expressed by any
random programmer, the set of optimization techniques which have been
implemented in today's popular compilers end up generating code which is
more efficient than that which would otherwise be written by hand by any
random programmer.

Naturally, there is always someone somewhere who is quite capable of
performing enough code voodoo to churn out more efficient code than that
which is produced by a compiler. Even in that case, there is the problem of
how fast he is able to write it, how fast the code is executed and the
relation between how much time was spent writing it and the added value
which has been obtained.

As a somewhat related oddity, here is a talk by Guy Steele himself[1]. In
it, he discusses some techniques he employed to write a couple of programs,
along with some optimization tricks he employed. Among those, he refers in
some parts how he reduced the program size by using the value of some
opcodes as constants. I doubt that today's compiler writers implement these
sort of tricks. This means that mr Steele's code is better than the
equivalent code which might be generated by a compiler. But the thing is,
not everyone is as proficient at it as mr Steele, or even close to it, which
brings us back to the assertion I've made.


Rui Maciel

[1] http://www.infoq.com/presentations/Thinking-Parallel-Programming

 

[Ben Bacarisse]

This means that mr Steele's code is better than the
equivalent code which might be generated by a compiler. But the thing is,
not everyone is as proficient at it as mr Steele, or even close to it, which
brings us back to the assertion I've made.

s/Mr/Dr/ Not that people bother so much with titles these days, but if
you are going to be formal, using the wrong one defeats the purpose!