Author Topic: Hunchback aka inquisitivemind.  (Read 125857 times)

Offline ka9q

  • Neptune
  • ****
  • Posts: 3014
Re: Hunchback aka inquisitivemind.
« Reply #225 on: July 17, 2012, 09:26:58 AM »
Code: [Select]
vec3 tensor = anchor_pt + direc_vec;

is more comprehensible than

Code: [Select]
vec3 tensor;
vec3_copy( &tensor, (vec3 *) &anchor_pt );
vec3_add( &tensor, &direc_vec );

This is exactly why I'm writing my new astrodynamics package in C++ rather than the C I used 30 years ago. (Yes, I know that some libraries already exist, but I'm doing this largely to learn some of the algorithms.)

But I'm concerned that performance will suck. I'm sure it'll be fine for running out predicts for a satellite, or tracking one in real time, but when you're doing orbit determination, or even better a complex interplanetary trajectory design, I expect to iterate my routines quite a few times and then performance will become important again.

Offline cjameshuff

  • Mars
  • ***
  • Posts: 372
Re: Hunchback aka inquisitivemind.
« Reply #226 on: July 17, 2012, 11:19:22 AM »
Quit a bit on the rantish side, but he raises some good points.

Well, the site is titled "Stevey's Drunken Blog Rants".


A legitimate criticism against C/C++ is the difficulty of pointers and pointer expressions.  Modern languages have fallen all over themselves in the rush to avoid the low-level ugliness of actual machine addresses and underlying storage.  Yet in the C world, pointers are highly necessary, especially in C's system-programming role.  However, Perl takes everything that was bad about pointers in C, but leaves us without the ability easily to debug them.  No wonder, then, that Perl programs that make heavy use of references are now all of a sudden suffering huge heap bloat because the garbage-collector (that magical piece of runtime software that's supposed to free the programmer from the drudgery and error-prone tedium of memory management) can't figure out whether something is freeable or not.

Apart from a different choice in operators, I honestly don't see a good way to make pointers any simpler or clearer than they are in C (with the exception of the syntax for function pointers). Any syntax that would make the simple cases clearer would add more clutter that makes the complex cases less clear. However, I don't see any particular benefit to having them in a higher level language...


Quote
Perl also has "contexts", which means that you can't trust a single line of Perl code that you ever read.

This is the single biggest criticism I have against Perl.  In its attempt to be a weakly-typed language, it has succeeded only in being an inscrutably and dangerously typed language.  I can't count the number of times my clients had to deal with obscure bugs caused by code in which the inferred in-context type didn't match the actual in-context type, and so the value was silently misinterpreted.

Contexts were what finally pushed me to lump Perl in with the esoteric languages. How can anyone treat such an inherently obfuscated language as anything but a joke? Forth requires a different mindset to work with, but fundamentally does make sense. Perl tries to catch you off guard...

For text processing or general quick scripting, I use Ruby. It has its share of problems, its approach to language design could be considerably more disciplined (several bad ideas were added early on, many copied from Perl, and many are now deprecated or no longer supported), but it's nothing like the monstrosity Perl has become, while providing much of the same functionality. (Given the earlier discussion on web technologies, though, please note that I specifically mean Ruby, not Rails.)


But yes, efficiency.  The sad fact is that the alleged near-C performance of C++ code is typically achieved only if you eschew many of the useful features of C++.  Transparency at the application level can only happen if you accept inefficiency at the machine-code level.  While you can optimize with clever use of references and coding that avoids temporaries, there is overhead.

There's often a tradeoff with abstraction. For instance, vector math can suffer from treating vectors as discrete entities when you aren't using SIMD to operate on the components in parallel and can operate on each component individually. Working with vectors means tracking intermediate values for all components which can mean extra work moving data around, while working on one set of components at a time can allow the same calculation to be done with fewer registers and no reference to main memory.

However, operator overloading is fundamentally just a different way to say which functions you're calling. I have a hard time seeing well-written operator overloading accounting for a 400% increase in execution time over equivalent C code.

Offline Lunchpacked

  • Mercury
  • *
  • Posts: 24
Re: Hunchback aka inquisitivemind.
« Reply #227 on: July 17, 2012, 02:24:13 PM »
not to be a busybody, or anything, but this thread turned from the idiocy of hunchbacked to programming  java or websites or something. that's all well and all, but wouldn't it be better to have a programming discussion in the off topic boards rather than hunchbackeds thread in the hoax board? :)

Offline JayUtah

  • Neptune
  • ****
  • Posts: 3787
    • Clavius
Re: Hunchback aka inquisitivemind.
« Reply #228 on: July 17, 2012, 02:38:12 PM »
But I'm concerned that performance will suck. I'm sure it'll be fine for running out predicts for a satellite, or tracking one in real time, but when you're doing orbit determination, or even better a complex interplanetary trajectory design, I expect to iterate my routines quite a few times and then performance will become important again.

Here's the benefit of my long experience.  If this is something you're writing for work, write it in a language and a style that's maintainable and comprehensible.  Then spend your money on faster silicon.  Seriously.  Engineering time runs in the hundreds of dollars per hour.  It costs thousands of dollars to optimize code, and thousands of dollars more over the life cycle of the code to maintain unclear (i.e., optimized) code.  Spend that money on faster hardware, because it's guaranteed to give you a more predictable, more useful performance increase than trying to bum inefficiencies out of the code by hand.
"Facts are stubborn things." --John Adams

Offline JayUtah

  • Neptune
  • ****
  • Posts: 3787
    • Clavius
Re: Hunchback aka inquisitivemind.
« Reply #229 on: July 17, 2012, 02:47:20 PM »
not to be a busybody, or anything, but this thread turned from the idiocy of hunchbacked to programming  java or websites or something. that's all well and all, but wouldn't it be better to have a programming discussion in the off topic boards rather than hunchbackeds thread in the hoax board? :)

Yes, I move we continue this in a new thread.
"Facts are stubborn things." --John Adams

Offline Glom

  • Saturn
  • ****
  • Posts: 1102
Re: Hunchback aka inquisitivemind.
« Reply #230 on: July 17, 2012, 03:13:07 PM »
not to be a busybody, or anything, but this thread turned from the idiocy of hunchbacked to programming  java or websites or something. that's all well and all, but wouldn't it be better to have a programming discussion in the off topic boards rather than hunchbackeds thread in the hoax board? :)

Yes, I move we continue this in a new thread.

NEW THREAD!  WHORE OFF!  I mean NEW THREAD!
« Last Edit: July 17, 2012, 03:15:03 PM by Glom »

Offline JayUtah

  • Neptune
  • ****
  • Posts: 3787
    • Clavius
Re: Hunchback aka inquisitivemind.
« Reply #231 on: July 17, 2012, 05:34:26 PM »
Well, the site is titled "Stevey's Drunken Blog Rants".

Didn't notice that.  I find the ad hominems against Larry Wall somewhat disturbing.  Yes, the guy is an autocrat when it comes to Perl, and yes he has strong delusions of grandeur.  But I'd have toned it down.  You can point out those effects on the final product without the value judgment.

Quote
Apart from a different choice in operators, I honestly don't see a good way to make pointers any simpler or clearer than they are in C...

Agreed, and I'm not suggesting we try.  The pointer data type is crucial to C programming, and it's not a difficult concept.  There are two typical "gotchas" and you've identified one of them:  pointers to function types.  The other is related, and that's whether array or pointer operators take precedence, a.k.a. how properly to declare and handle char *argv[].

Quote
Contexts were what finally pushed me to lump Perl in with the esoteric languages. How can anyone treat such an inherently obfuscated language as anything but a joke?

Perl evangelists tell you it's because you aren't smart enough to understand it or open-minded enough to realize how beautiful it is.  One can write comprehensible Perl.  But the evangelists will tell you you're not using the language to its full potential.

Quote
There's often a tradeoff with abstraction. For instance, vector math can suffer from treating vectors as discrete entities when you aren't using SIMD to operate on the components in parallel and can operate on each component individually.

Very astute.  There's the perennial question of whether a vector should be

Code: [Select]
struct vec3 {
  double x, y, z;
};

or

Code: [Select]
struct vec3 {
  double coords[ 3 ];
};

In the latter case affine arithmetic can be implemented as a loop.  Optimizing compilers for vector CPU architectures know how to vectorize inner loops, so they implement looped arithmetic as vector instructions.  This is how we did it on the old IBM/3090 and on the Cray.  For E2, E3, or P3 points the speedup isn't especially noticeable since the setup required to start the vector instructions eats up most of the vectorization.  But if you're transforming a NURBS surface with 200 control points and a 190-element knot vector, the speedup is enormous.

Quote
Working with vectors means tracking intermediate values for all components which can mean extra work moving data around, while working on one set of components at a time can allow the same calculation to be done with fewer registers and no reference to main memory.

Well we got lazy on the Cray, which stores intermediates in cache registers where they can be fetched into CPU registers in 1 cycle.

Quote
However, operator overloading is fundamentally just a different way to say which functions you're calling. I have a hard time seeing well-written operator overloading accounting for a 400% increase in execution time over equivalent C code.

Yeah I'd still like to see that code, because I feel confident that either I or someone on my team could have made it run faster.  In the straightforward C++ programming mindset you're probably going to create lots of temporaries.  That's C++'s dirty little secret.  But there is some syntactic handwaving you can do (e.g., make sure all your RHS values are received as references) to make it so that for most arithmetic you're dealing (under the hood) with references to existing objects.  Back when we were doing this for the aforementioned spline surfaces as first-class objects, we had some whiz programmers who knew how to do this.

Representing design geometry as C++ objects really generates a lot of very fun debate.  Lots of size/speed tradeoff discussions as well as where to generalize the arithmetic for maintainability.  If the dimensionality of a point or vector is a stored parameter, then linear arithmetic can be implemented in a common base class as loops bounded by the dimensionality.  But how to store it effectively, when your model is of a Boeing 777 airframe containing approximately 67 gazillion points?
"Facts are stubborn things." --John Adams

Offline gillianren

  • Uranus
  • ****
  • Posts: 2211
    • My Letterboxd journal
Re: Hunchback aka inquisitivemind.
« Reply #232 on: July 17, 2012, 08:11:49 PM »
Okay, just looked him up.  That's the guy!  That's the guy I was in a writing group with!  That's really random.
"This sounds like a job for Bipolar Bear . . . but I just can't seem to get out of bed!"

"Conspiracy theories are an irresistible labour-saving device in the face of complexity."  --Henry Louis Gates

Offline ka9q

  • Neptune
  • ****
  • Posts: 3014
Re: Hunchback aka inquisitivemind.
« Reply #233 on: July 17, 2012, 08:36:35 PM »
Here's the benefit of my long experience.  If this is something you're writing for work, write it in a language and a style that's maintainable and comprehensible.  Then spend your money on faster silicon.  Seriously.
If this was for work, I'd say exactly the same thing. It's not; it's a hobby project.  But I'm still writing it in C++ rather than C, and I won't actually worry about performance unless or until it actually becomes a problem.

Offline ka9q

  • Neptune
  • ****
  • Posts: 3014
Re: Hunchback aka inquisitivemind.
« Reply #234 on: July 17, 2012, 08:45:58 PM »
Agreed, and I'm not suggesting we try.  The pointer data type is crucial to C programming, and it's not a difficult concept.
I'm really glad to see I'm not alone on this. Back when Java was the new rage, it was fashionable to trash pointers and say how inherently evil the concept was. I was always baffled by this because, when I learned C, I thought pointers were one of its most elegant and powerful features. Power does breed danger, of course, and you can get yourself into a lot of trouble with them, but I couldn't see that as a reason to get rid of them entirely. Just learn how to use them properly and safely, as you would a circular saw or power drill.

Sure, I burned myself enough times but I came up with a few simple tricks that seemed to work wonders. They're probably old hat now, but I came up with them in the mid 1980s while writing the first multitasking Internet stack for the IBM-PC. I used dynamic memory very heavily, so one of my practices was to always clear a pointer when its value is no longer valid, such as when it is passed to free(), or when it passes a data structure to some other function that will take responsibility for freeing it. I also hacked the malloc and free routines to detect pointer corruption and double frees. That alone caught a huge number of bugs.

But what did I know? I'd only been programming in C for 20 or so years when Java became hot, and so I couldn't really appreciate how vastly superior all the newer super-high-level languages really were...

« Last Edit: July 17, 2012, 08:47:53 PM by ka9q »

Offline carpediem

  • Venus
  • **
  • Posts: 88
Re: Hunchback aka inquisitivemind.
« Reply #235 on: July 17, 2012, 09:37:52 PM »
Okay, just looked him up.  That's the guy!  That's the guy I was in a writing group with!  That's really random.
You were in a writing group with Hunchbacked?
I, for one, would love to read some of HB's writings. Are they available somewhere on the web?

Offline gillianren

  • Uranus
  • ****
  • Posts: 2211
    • My Letterboxd journal
Re: Hunchback aka inquisitivemind.
« Reply #236 on: July 18, 2012, 12:38:32 AM »
No, not Hunchbacked.  Larry Wall.
"This sounds like a job for Bipolar Bear . . . but I just can't seem to get out of bed!"

"Conspiracy theories are an irresistible labour-saving device in the face of complexity."  --Henry Louis Gates

Offline JayUtah

  • Neptune
  • ****
  • Posts: 3787
    • Clavius
Re: Hunchback aka inquisitivemind.
« Reply #237 on: July 18, 2012, 01:12:20 PM »
Okay, just looked him up.  That's the guy!  That's the guy I was in a writing group with!  That's really random.

Wow, that's actually a feather in your cap if you hang out with a lot of geeks.
"Facts are stubborn things." --John Adams

Offline ka9q

  • Neptune
  • ****
  • Posts: 3014
Re: Hunchback aka inquisitivemind.
« Reply #238 on: July 18, 2012, 02:18:17 PM »
Speaking of Hunchbacked's writings, when he was here as 'inquisitivemind', somebody (I think it was me) asked him if he was Youtube user 'hunchbacked'. He said "Yes. How did you know??!" I told him that his idiosyncratic writing style was absolutely unique and that I could recognize it anywhere.

One of the defining features of the crank as listed in the Wikipedia article is a refusal to use standard terminology. He certainly fits the mold with words like "incoherences", referring to the lunar rover as a "jeep", and so on.

Offline gillianren

  • Uranus
  • ****
  • Posts: 2211
    • My Letterboxd journal
Re: Hunchback aka inquisitivemind.
« Reply #239 on: July 18, 2012, 04:41:14 PM »
Wow, that's actually a feather in your cap if you hang out with a lot of geeks.

It also shows exactly what kind of geek I am, that it took me this long to put it together, and if I remember correctly, I used to spend Thursday evenings in his house.
"This sounds like a job for Bipolar Bear . . . but I just can't seem to get out of bed!"

"Conspiracy theories are an irresistible labour-saving device in the face of complexity."  --Henry Louis Gates