AnsweredAssumed Answered

vrf Fast calculations of transient response!!

Question asked by VRFuser on Jan 10, 2006
> Not necessarily. More objects can in some cases be faster since they
> can be compiled, as opposed to using objects which have to be
> interpreted.

However, don't forget that nothing in VEE is truly "compiled" anyway. I've
looked for every reference I can find about VEE's compiler, and the one that
I trust more than any other is Greg Goebel's: VEE compiles to p-code. That's
what I suspected all along, but had doubts when the subject came up a few
years ago. This is an ancient technique and all p-code machines run the same
way: they interpret the p-code.  Even the latest and most up-to-date, like
MSIL - CSharp's (usual) target. The best one can do is build the interpreter
in silicon in which case one has a RISC of the p-language. Er, in which case
one can drop the "p"

Long time readers of Byte mag. are asked to discount the famous Pascal
bootstrap compiler. That was a special case!

At any rate, the profiler is definitely a great starting place, as is the
specification of types (I guess). Although veeData.h doesn't specify the
structure of a VDC, one can be virtually certain it includes members for
veeType and veeShape. In fact, I wouldn't be at all surprised to lean that
it's quite similar to VARIANT, where veeType is the very first member. It's
common to specify polymorphic types where the type specifier is the first
member of the structure: until you know the type, you have no idea how many
bytes to expect or what the rest of the structure looks like or even how the
bytes are encoded. Your pointer always points to a type code.

I've seen this stricture mentioned before: specify type to compile. I don't
know how this compiler works, but I don't see where it really gains that
much with type specification, or why specifying type would allow
p-compilation. It would be very unwise (IMO) to make the p-interpreter type
specific, and the machine can always resolve type in just a few cycles by
dereferencing one pointer. Put another way, as a language designer &
implementer, I've always been puzzled by this particular quirk. I've done it
the other way around: there are never any restrictions on type unless
specified in source (we match with that point) and if there are, the support
routines are *not* responsible for checking type, the manager is. Support
routines must be able to handle the incoming type whatever it may be. Either
way, it has absolutely no effect on p-compilation whatsoever.

However any of this works out with VEE, one thing is certain: your code
never gets compiled to x86 and it always runs hundreds or thousands of times
slower than the x86 equivalent would. For the OPs purposes it doesn't matter
anyway. I thought maybe Matlab would be faster but I just didn't mention it.
Those folks have been tweaking their stuff at a very low level for a long,
LONG time.

You are currently subscribed to vrf as:
To subscribe send a blank email to "".
To unsubscribe send a blank email to "".
To send messages to this mailing list,  email "". 
If you need help with the mailing list send a message to "".
Search the "unofficial vrf archive" at "".