Please not Python - it's as verbose as C++ and much slower than alternatives
like perl. Surely rapid prototyping should involve less typing?
- Dale
On Thu, Jan 04, 2001 at 08:03:07PM -0800, Robert W. Cunningham wrote:
> Kevin Lawton wrote:
>
> > So how do you code this, so that in one high-performance
> > case you don't have the 'this' pointer pushed. But perhaps
> > in a lower performance case, you have more than one
> > instance (like cosimulation in bochs where you have 2 CPU
> > simulations running head-to-head), in which case the 'this'
> > pointer is necessary and not so much of a problem.
> >
> > // high performance case: all static member functions
> > void
> > some_class:some_function(unsigned a)
> > {
> > some_instance.xyz = a;
> > }
> >
> > // low performance case: this pointer available
> > void
> > some_class:some_function(unsigned a)
> > xyz = a;
> > -or-
> > this->xyz = a;
> > }
> >
> > Had the C++ designers thought of this, they could have easily
> > added a directive that would let you bind a specific instance
> > name to the class for the static case. The address of that
> > instance would then effectively be the 'this' pointer. And
> > no nasty #define hacks would be necessary.
> >
> > Handling high performance callbacks suffers similar problems.
>
> These FEW things are *exactly* the cases where using C makes sense. Maybe
> even hand-tuned assembler, if it is really going to be called that often and
> overhead is really that critical. Special cases warrant special solutions.
>
> That's, what, 0.01% of the code base? Literally a few calls, right? Does
> that warrant tossing out an entire language because it fails to handle one
> specific case?
>
> Hell, no!
>
>
> > I remember from my days of reading through the Stroustrup book
> > and even taking a C++ class, there were some real _major_
> > f*#! ups in the design, but they were all in features you talk
> > about eliminating.
> >
> > But, rather than go into a rant about C++, I leave off with the
> > following quote"
> >
> > "C makes it easy to shoot yourself in the foot. C++ makes it harder,
> > but when you do, it blows away your whole leg." - Bjarne Stroustrup
>
> Which is why I STRONGLY recommend using only the lightest-weight parts of
> C++ that offer the greatest benefits. I haven't looked at ObjectiveC that
> closely, but remember that Next did write nearly an entire OS in that
> language, and it ran quite well. Something to look at as an example of
> high-performance system-level OO.
>
> Let's allow for the POSSIBILITY that a diluted form of C++ can help Plex86.
> And those of us that want to bang our heads against it can do so without
> forking the project!
>
> To tell you the truth, I have yet to find ANY case where full C++ is the
> "best" language to use. For very high-level OO stuff, I find scripting
> languages to be superior (Python and Ruby). I have written several
> application-specific Python extensions in lightweight C++ to implement the
> high-speed stuff, then kick back and let the script do the rest. There is a
> huge productivity boost when doing R&D and rapid prototyping without a
> compiler in the develop-test loop.
>
> Since Python doesn't fit in a ROM either, I have used py2c to get some quick
> and dirty C code generated, then massage that (in a Hannibal Lecter sort of
> way - the generated code ain't all that purty) to become my final app. Or
> (more often) I sue the Python code as the design document for my C code.
> Either way, the productivity is astounding. I have also used the route of
> moving more and more of the app into Python callable modules, then finally
> write a C skeleton to tie the modules together and eliminate the last Python
> code. Both ways work, and are hair-on-fire fast.
>
> Does Plex86 allow for a tightly integrated modeling/scripting environment to
> be used for prototyping? It would be great to be able to quickly gen up an
> algorithm in Python or Ruby, debug it at a high level and make sure it works
> before taking it to low-level code. It would allow multiple alternatives to
> be tested quickly and easily, and help avoid pursuing dead-ends in low-level
> code.
>
> If Plex86 were "g++ compatible", it would be possible to make the whole thing
> a Python module (set of modules?), with all required data structures
> exposed. Python has at least two ways of making C++ code accessible to
> Python scripting.
>
> While I have never personally tried to merge an existing project with Python
> (I've always started with a clean slate and proceeded incrementally), it is
> at least a tantalizing possibility that would exist if Plex86 were to become
> "g++ compatible".
>
> Your current hashing problem is EXACTLY the kind of problem best solved in an
> environment that supports rapid prototyping and even some simple simulation
> (of the CPU caches, in this case). There are enough knobs to twist that the
> "best" algorithm is far from obvious. It would help if there were a way to
> quickly and easily test and weed out the losers, before committing the one or
> two finalists to low-level code and "real world" testing (always the final
> arbiter). It is a straightforward task to instrument Python code to the
> level of providing full simulation capabilities (actually, I tend to use
> co-simulation, but that's just my preference).
>
> Not that glomming a Python interface onto Plex86 would be practical or
> useful! But it is a real possibility, one of many.
>
>
> -BobC
>
>
