Re: [NTLK] Drawbacks of C / C++ vs. Newtonscript?

From: James Witte (jswitte_at_bloomington.in.us)
Date: Sat Sep 28 2002 - 00:10:47 PDT


> Aside for the ease of using C++ / C with newton programs, is there a
> benefit in doing so in regards to speed? Say, I have to continually call

  Yes, there's a performance hit each time the Newtonscript thread pauses
and the C++ code gets run, and when the C++ code reads/writes stuff
to/from the Newtonscript object heap. But I don't know how much - never
done benchmarks and don't know how exactly the code is kept in memory (are
the C++ routine frames always kept around on some heap in case they happen
to be used again, etc)

> and assuming I'm just passing pointers to structs that would not need
> any conversion/casting to a useable C type))?

  Probably there would be a performance hit with the C version. You can't
just access a Newtonscript object directly from C++ like, say
"myNewtonscriptObect->anArray[5]" to mean (in NS)
"myNewtonscriptObject.myArray[5]" but have to access it through a
RefArgVariable, then extract a slot from it (to get another RefArg) then
get an array index from it (a third RefArg) and then finally convert it to
a number or whatever.. I think. Some types, like binary objects (and
MAYBE any type whatsoever, if you know the format of it), can be accessed
using the WITH__LOCKED_BINARY macro pair which does some pointer locking
voodoo. This is how one Fractal program works: the C code draws a bitmap
directly into a newton bitmap object, then calls back to the NS program to
update the view with viewDraw (or maybe the C routine just quits
altogether)

> I guess what it boils down to is, if I am indeed concerned with speed,
> would I be better off coding in newtonscript entirely / maybe some arm
> ASM where needed) instead of using C / C++?

  In NTK there is a native keywork, which I think will boil NS down to ARM
assembly (though there might still be a performance hit IMO, but maybe not
as great as calling a seperate NTCK defined C function). As for an ASM
function like Roger Milne did for his ModPlayer, I have NO idea how you
even get data in and out of..

  Remember that as far as the released C++ docs go, there are a few things
you can't do. You can't have persistent data objects between invocations
of the C++ routines, and (it says) you can't have virtual functions, and a
few other things. Paul G. figured out how to make virtual functions work
(I think), but he was writing P-Class code, and not specifically NTCK
module code, so that *might* not apply (I really have no idea)

  You can of course store persistent data on the NS heap, but then you
have penalties everytime you access it, and if there's too much of it
(like the VBOs in the Mad Max MP3 player) it tends to drive the VM paging
system wild ("Oh -10061, don't we love thee..") You can store small
amounts of data (two strings and two longints?) using the name server as
detailed by Paul G. in one of his Bowels articles. Theoretically, you
could allocate large chunks of memory either in the system memory domain
or could allocate another domain, but I don't know if anyone knows how to
do that.

  And of course, (normal) C++ routines interrupt the execution of
Newtonscript programs. I saw normal because they could theoretically be
forked into preemmptively-handled tasks running in parallel with the
inker, NS interpreter, etc. The Waba interpreter *may* do this, I'm not
sure.

Jim

>
> I don't want to traipse too far down one road only to find later that I
> really should have taken the other.

-- 
Read the List FAQ/Etiquette: http://www.newtontalk.net/faq.html
Read the Newton FAQ: http://www.chuma.org/newton/faq/
This is the NewtonTalk mailing list - http://www.newtontalk.net/


This archive was generated by hypermail 2.1.5 : Mon May 26 2003 - 12:59:23 PDT