In article
<b716b85c-ddfb-4bc5-b90a-5ac81624fd41@[EMAIL PROTECTED]
>,
Marshall <marshall.spight@[EMAIL PROTECTED]
> wrote:
>On Jul 1, 7:40 am, hru...@[EMAIL PROTECTED]
(Herman Rubin) wrote:
>> In article <ddfb7$48688db5$82a1e228$25...@[EMAIL PROTECTED]
>,
>> I have programmed in Fortran, C, and assembler for
>> different machines.
>Yes, those are sure good ones. Fond memories. Have
>you had a chance to work with any of the languages
>that have come out in the last 35 years? Some of them
>are quite good.
>> I am quite aware of even the
>> fact that efficiency for subroutines requires taking
>> into account the differences in the different machines,
>> and I have also stated that I can see how to produce
>> a somewhat high level assembler language easy to use.
>Certainly high level assembler is easier to use
>than low level assembler. Or machine language. But
>it will be harder to use than pretty much anything else.
I have often found that those who produce the hardware
and software seem to have no idea of much of anything.
Efficiency is im****tant, and a decent user, with knowledge
of machine architecture and what causes loss of efficiency,
should at least be able to tell the compiler/assembler
how to do things.
>> Those who think HLLs are such a great idea, here is a
>> challenge. The function I am giving arises naturally,
>> and it is quite difficult to do EFFICIENTLY in any HLL.
>One might have an application that has to respond in
>such-and-such a way within x number of milliseconds.
>But "efficiency" by itself is not a goal for software
>development. It might be a means to an end, but never
>a goal in its own right.
>> Let x be a positive real number, whose binary expansion
>> is x = \sum a_i/2^i, a_i = 0 or 1. Then
>> f(x) = \sum i*a_i/2^i.
>> I have done some work on methods of generating non-uniform
>> random variables from uniform bits. There are some technical
>> re****ts available from the Purdue Statistics Department.
>> Among them are some I call "infinite precision", in that
>> no computer roundoff is involved. The easiest one of these
>> is to generate the density 2x from 0 to 1. The entire
>> algorithm is
>> I = distance to the first 1 in a random bit stream;
>> discard this part of the bit stream
>> X = U with the I-th bit after the binary point
>> changed to 1.
>> Alas, few of these are efficient, except possibly on an FPGA,
>> but the amount of work is finite random for all distributions
>> in any number of dimensions with lower semi-continuous density.
>> I have a recent paper with Brad Johnson on acceptance-replacement
>> generation of exponential and normal random variables, using
>> exponentials to test and reuse of successful test exponentials.
>> These vectorize or parallelize well if one changes the "control"
>> part of the algorithm somewhat, and that consideration also went
>> into the design of the algorithm.
>So, how many times is this code going to get executed, and
>in what application, and in what context? Unless the answers
>are severe, the correct course of action is to code it in
>the most straightforward way and forget it.
This latter code is going to be executed very many times if
it is used at all. A billion is well within possibility.
These are likely to be the most used non-uniform random
variables in an application, as they are also used in the
generation of others. The reuse of test random variables
occurred to me some 45 years ago, and is quite efficient
and cheap.
BTW, one consideration comes in when choosing the size of
constant arrays. From the computational efficiency staandpoint,
the larger the better. But it seems that if they are too
large, paging problems arise, as one is going to use them in
a random manner, all elements equally likely to be read.
If one could tell the compiler/assembler to put these in
one page, it might help.
>> I do know something about getting the power of the machine, and
>> doing operations beyond the low precision hardware. Even if only
>> partial, there should be a convenient way of including assembler
>> instructions in a program without losing "optimization"; I have
>> done that on the CYBER 205. I have also in my files a design for
>> a decent quick assembler for the 780; I cannot find what I did
>> on the 205, but I remember some of it, including the most complicated
>> single one.
>I never worked with the CYBER, but I did a lot of coding in
>Fortran on the good ol' 780. But you do know, don't you, that
>those days are gone? Not only are those machines obsolete,
>but the companies that made them are largely forgotten.
>I'm sure there are people reading this who have never heard
>of Control Data because they were born after it ceased to
>be a computer company. DEC was acquired by a bigger
>fish ten years ago which was then itself consumed by an
>even larger fish. Today my iPhone has more than 100 times
>the computing power of a 780.
The successor to the CYBER would have been a great success
if the company had given it any sup****t.
I doubt that your iPhone has that power for doing arithmetic;
it is probably designed for certain types of operations, but
not for any precision. But the 100 times the computing power
comes from 1000 times the speed together with 100 times the
size in computing units. Anyone understanding computer
hardware will know that the x86 series was a total mistake,
but I believe it is still the Intel hardware. The Power
hardware is reasonable but not that good, and I am looking
at AMD, which is now suing Intel.
For a straightforward coding problem, which will surprise
those looking at it carefully, is the calculation of
x - ln(1+x) to machine accuracy on the entire range x > -1.
The code can be written in Fortran or C, but if one does
not understand the machine, will have a sizable loss of
accuracy. Again, this code is likely to be used millions
of times or higher orders if it is used at all.
>The idea of assembly code inline in high level code made
>sense in the 1980s but not since. The idea of hand-coded
>assembly routines for speed made a lot of sense in the
>1990s, for performance-critical inner loops anyway. There
>are still a few scant places where that idea makes sense,
>but they are getting fewer and fewer. It is harder every
>year to outperform the compiler, and there is less reason
>every year to try.
Wrong. The compiler often fails to use the operations
needed for efficiency. It is even the case that what
the compiler does for efficiency is totally wrong even
if using the right operations.
One thing HLLs should have had for ages is a list before
the replacement statement or even in a subroutine call.
The reason is that the variables in the list can be
computed in whatever order the replacement statement
or the subroutine decides, and placed there. This is
different from a struct, which puts them in memory.
An example is the C frexp, which should have been an
inlined replacement statement with two variables to the
left of the equal sign; it might not even have any use
of memory. I believe that all the Power machines use
memory in converting between integer and float, either
way, and I suspect most others do. The 780 could do some
of that without using memory.
>I used to write assembly code for some different Adobe
>apps in the early 1990s: Photoshop and Premiere. The
>processor being targeted was the 486, and there was
>a nice chart you could flip through and see how many
>cycles each instruction was. You could come up with
>different approaches, sum up the cycle count, and
>compare.
>When the Pentium came out, that got a lot harder.
>Now there was a pipeline, and the cycle count wasn't
>so straightforward. You might be able to pair these
>two instructions, or not.
>These days the situation is ridiculous, with very long
>pipelines, multiple execution units, etc. etc. and you
>can't even *get* a chart.
Why not? You have a better idea of what is needed than
the compiler writer.
>> One danger of HLLs is that the user has no idea
>> of how long something will take.
>That's just simply not true. Languages like C++ and
>Java have quite transparent performance models; in
>fact this may even be a good part of why they're
>so successful. Even when using something wildly
>abstract like SQL, one can still get an execution plan
>out of the engine, and do various tweaks to change
>it. Not that one ever has much need to.
>> As for gotos, I find them easy to use,
>> and spaghetti code is best for spaghetti algorithms.
>Sure, gotos are easy to write, but what's usually im****tant
>for code is that it be easy to read and easy to maintain,
>and gotos are anathema to that.
Hah! They are much easier to read than following indentations.
Several levels of indentations especially.
Assembler language and the machine use gotos. The user
cannot do things efficiently without telling the machine
what to do.
One instruction I find missing on the "modern" machines I
have seen is a conditional skip of a few instructions; I
have never seen more than one. This would enable no loss
of pipelining. The compiler could count how many instructions
in a large number of cases from code.
>Marshall
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Department of Statistics, Purdue University
hrubin@[EMAIL PROTECTED]
Phone: (765)494-6054 FAX: (765)494-0558
|
