Re: LSE64 in standard Forth

John Passaniti wrote:
John Doty wrote:
False. I have yet to find a compiler that generates different code for *sp and sp[0]. At best, you're speculating. Why not actually look at the code emitted?

I was thinking of sp[1] followed by sp++, which might indeed be more expensive.

You're forgetting (or ignoring) the larger context. sp[1] followed by sp++ is one additional add of a constant value (8 in LSE64). The cost of an additional add verses the cost of:

adjusting the stack to allocate space for a temporary
copying sp[1] to that temporary
adjusting the stack to deallocate the temporary

On architectures that are register rich, the compiler may be smart enough to not allocate stack space and instead use a register. But even in that case, you are still copying from memory to a register first, an operation that doesn't need to occur.

Only if you have memory to memory arithmetic.


Again, you seem to put a lot of trust in the optimizer. I suggest you measure instead of trust.

I do measure when I think it matters. But what matters varies. How much *energy* does your variant take compared to mine? That's harder to measure, but it matters when you're running on batteries. And results will vary from processor to processor, compiler to compiler.

In any case, on a G4 PPC (the hardware I originally developed LSE64 on) using gcc 4.0.1 with -O2 (the usual optimization), I find your version is four bytes longer than mine and timing of the two matches to within 0.1%.

One thing I did measure in the early development was the difference between the "fast" and "fussy" ITC loops. I was very surprised at how small it is on all architectures tested (G4, Pentium, AMD64). Branch prediction works wonders. ;-)

But you and Neil find a small difference in your favor. I find a small difference in my favor. Bernd finds no difference. It seems there is little difference here, nothing worth much attention until some difficult application requirement forces a reexamination. From where I sit, it seems my lack of attention here was justified. But I'll buy you a chai anyway.


Understanding any program source requires understanding the source language and the benefits and pitfalls of that language. Weird, huh?

Reviewing source for a real application may require domain knowledge that takes years to acquire. If you put too many requirements on the job, nobody will be able to do it.

A prerequisite for reviewing source is to understand the language.

Indeed, but there is language and there is language. One doesn't write manuals in Shakespeare's English. Remember that the person with the domain expertise you need is probably *not* a programming specialist. Is a good reviewer going to study? Absolutely! Is that person going to reach the level of language competence that someone with decades of experience has? Of course not.


I haven't seen that at all. I've seen skilled C programmers use macros when they made sense, and advise against them when they don't.

"That's a subjective evaluation."

No, I've seen *reasons* given for both when macros make sense and when they don't. That's a critical difference here. You're just shooting from the hip.

Your reasons are subjective.


Yes, but it has a cost. It hides the concept that underscores the code.

It doesn't *hide* since you are free to go to the definition (usually at the top of the file). What it does is *name* the concept, which you seem to have a problem for.

Hmm. LSE64 forces a lot more naming of things than Standard Forth, a thing I consider positive, but some in the group have criticized. I have no problem with naming a concept.

Every time you claim to to have found some conceptual problem I have, you're wrong. Please stick to facts.

The problem I have with macros is one well known in the C community: while a macro names a concept, it does not automatically provide a clean interface. So there are a bunch of extra issues that a reader/reviewer/maintainer must consider when encountering a nontrivial macro as opposed to a function.


When the cost exceeds the benefit, that is obfuscation.

Give me the cost. Not in some abstract terms. Give it to me in something tangible.

The reviewer must examine each of your macros to see if they *might* do the wrong thing when expanded in a context you didn't anticipate. And, since that assessment is not guaranteed to be reliable, they must be alert while reading the use of the macros for surprises. Thus, the benefit of abstraction is lost: a careful reviewer must mentally expand the macros as encountered: they can't be treated as "black boxes". A maintainer has to take care that they don't use the macros outside *your* expected envelope. Those are costs.

Parentheses would help.

Inline functions might be better in principle, but I have little experience with them so I decided to be conservative and straightforward here. The prejudices of someone who builds spacecraft, I guess.

Stop playing these ridiculous games where you justify your views based on nothing more than vague statements. Start giving an objective and verifiable basis for your claims.

I cite opinions of actual users. So do others here. Why not jump on them?

I *do* jump on them. One of my roles here in comp.lang.forth is donate my services as a nonsense detector. You aren't special, John. You're
just the latest to offer unsupported opinion dressed up as fact. And when anyone does that, my skeptical side comes out.

You're not skeptical, you're just cranky. And you've offered many unsupported opinions. A conservation law at work?


Well, you have in this case done an actual experiment. I agree it is meaningful. Now, what about *my* experiment of looking for Forth at the biggest conference on astronomical technology of 2006 and finding none? Doesn't that mean something, too? I see an awful lot of denial in this group.

When I compared my code to yours, the objective basis I used to make a judgement was execution time. I also looked at the code generated by the compiler for three cases (no optimization, "normal" optimization, and hyper-insane-goofy optimization). I looked at the assembly listing, classified each opcode in terms of memory cycles, and then used my past experience to judge if the same would occur on platforms I don't have access to. I had no biases going into it other than a strong suspicion.

You on the other hand didn't go to the conference unbiased. Your comments about Standard Forth predate the conference, so you went in with that baggage.

Unsupported opinion. I went consciously looking to see what 21st century astronomers were doing with Forth. That's my customer base, after all, and I'd like to offer support in *whatever* approach they find comfortable.

Finding no Forth at all there certainly hardened my attitudes toward Standard Forth, though. Standard Forth turned a garden into a desert.

I also went there with a rather negative opinion of Python. A couple of "early adopters" had worked with me in the 90's, and their Python code had turned into a maintenance headache. But seeing people doing good stuff in Python certainly got my attention, in a positive way. Unfortunately, Python is not a Forth substitute.

You also went in with a sentimentalized nostalgia about the role of Forth in astronomy.

Unsupported opinion. Forth was *extremely* valuable as a tool in astronomy, and nothing has really replaced it. Instrument control has gotten harder without it.

LSE played a critical role in the development of technology that won over $100 million in grants and contracts for my lab at MIT. That kind of economic effectiveness also gets my attention (especially now that I'm an independent consultant). I don't think that's nostalgia.

So frankly, I'm not sure how to interpret your comments about your "experiment."

I have no problem with comments about the Forth world not promoting the kind of rich communities seen with other languages. It's depressing and I think is driven in large part by dogma. If that's your specific lament regarding the astronomers, I agree with you.

I don't find you especially objective.

Given your distorted view of what objective means, I'll take that as a complement.

The issue here isn't that my code runs faster. The margin isn't huge, but is easily measurable.

Not measurable on my hardware. The size is, and your code is bigger.

The issue is that as I look over the LSE64 code, I see *plenty* of opportunities for not just optimization, but expressing the code in terms of some basic abstractions that would make porting to Standard Forth far easier than you evidently believe it to be.

I should point out that porting to Standard Forth was definitely *not* on my mind when I wrote the code. And I still can't see any point to it.


Could be. It's 0.3. It was put together in haste. I'm certainly not not going to claim it's the best coded thing in the world. For the SXC instrument on the HETE-2 satellite I once spent hours playing with rearrangements of code to eliminate a single cycle of pipeline stall in an inner loop to make an improved image processing algorithm possible. But it's usually not worthwhile to push that hard.

Again, when I looked at your code, it wasn't necessarily because I wanted to squeeze a few cycles out of it. I see opportunities for that, but I see stronger opportunities for identifying the central concepts that underscore your code and coding them in a way that promotes portability.

Could be. You want to contribute code to the project?


You said that abstraction has a cost. The lack of abstraction also has a cost. That cost is demonstrated by your statements that in order to port LSE64 to Standard Forth, you would have to code using the lowest-level Forth primitives. So the cost here is obvious-- you see something as impractical and that thus limits you.

Now who's talking in unsupported generalities?


Where I work, this would be the start of a conversation, and the end would be bootstrapping others. Where you work, apparently it is a thing of dread.

Not so much dread, but a serious waste of time. In this case, we work on different continents and speak different native languages. We don't have a lot of opportunity to get together, talk, and wave our hands. Physics is pretty easy to discuss, but it gets harder as we move away from that. So unnecessary barriers are to be avoided.

Thankfully, your work environment isn't shared by me and most of the other people I know. One of the things I really enjoy is how we collectively bootstrap each other. Nobody where I work considers it a waste of time to learn.

You just can't correctly imagine my world, can you? We learn *all the time* from each other. You think folks at a university have something against learning? But when we're trying to collectively comprehend a mix of x-ray spectroscopy, solid state physics, statistics, linear algebra, and electrical engineering, confusion over an exotic (to some) programming technique is unwelcome if time is limited. Under other circumstances it would have been fun. How do you think I learned this stuff in the first place? I spent 25 years at MIT as a researcher, often supervising student projects. What a great way to learn!

--
John Doty, Noqsi Aerospace, Ltd.
--
Specialization is for robots.
.

Relevant Pages

  • Re: Beyond CL?
    ... what people mostly defend is an attempt to change ... because they know the cost of changing the standard is generally so huge ... change to a part of the language can be done without breaking the rest ...
    (comp.lang.lisp)
  • Re: C++ in the kernel
    ... language remains standard. ... what exactly is "standard" in this context? ... all I'm proposing is giving it more ... Tree macros are worse, among other ...
    (freebsd-arch)
  • Re: visual C++ 6
    ... The approach taken by the C++ committee, is that C++ is a library-programming language in addition to systems programming and applications programming. ... for example C++ provides a complex type in its standard library that can be implemented by using the language itself. ... Regarding macros, AFAIK they are deemed unnecessary, but of course it provides the preprocessor of C95. ...
    (comp.lang.c)
  • Re: Was there a schism between R4RS and R5RS?
    ... reading a lot about people's take on R4RS. ... did they get added to the standard in R5RS? ... probably there wasn't a schism, but, macros seem like a "big" addition. ... Any language that hasn't lisp-equivalent macros is a shame, ...
    (comp.lang.scheme)
  • Re: The War On HLA
    ... If you're assuming that macros' only purpose is for "in-line" functions, ... languages demonstrate the ability of using macros to extend the language. ... I would ask why you're using Delphi in the first place. ... programming language (i.e., you can assign them to variables, ...
    (alt.lang.asm)