怎么快速计算瞬态响应？

>不一定。
在某些情况下，更多的对象可以更快，因为它们可以被编译，而不是使用必须被>解释的对象。但是，不要忘记VEE中的任何内容都无法真正“编译”。
我找到了关于VEE编译器的每一个参考资料，而且我比任何其他人更信任的是Greg Goebel：VEE编译为p代码。
这是我一直怀疑的，但怀疑几年前这个话题出现了。
这是一种古老的技术，所有的p代码机都运行相同：它们解释p代码。
即使是最新的，也是最新的，如MSIL-CSharp（通常）的目标。
最好的方法是在硅片上构建解释器，在这种情况下，人们可以使用p语言的RISC。
呃，在这种情况下，人们可以放弃Byte mag的“p”长时间读者。
被要求打折着名的Pascalbootstrap编译器。
这是一个特例！无论如何，探查器绝对是一个很好的起点，类型的指定（我猜）。
尽管veeData.h没有指定VDC的结构，但实际上可以肯定它包含成员forveeType和veeShape。
事实上，我不会感到惊讶，因为它非常类似于VARIANT，其中veeType是第一个成员。
通常指定多态类型，其中类型说明符是结构的第一个成员：在知道类型之前，您不知道要预期多少字节或结构的其余部分是什么，甚至不知道字节是如何编码的。
你的指针总是指向一个类型代码。我已经看到过前面提到的这个限制：指定要编译的类型。
我不知道这个编译器是如何工作的，但是我没有看到它在类型规范中真正获得了什么，或者为什么指定类型会允许编译。
使p-interpreter类型特定是非常不明智的（IMO），并且机器总是可以通过引用一个指针在几个周期内解析类型。
换句话说，作为语言设计师和实施者，我一直对这个特殊的怪癖感到困惑。
我已经完成了相反的方式：除非在源代码中指定（我们与该点匹配），否则永远不会对类型进行任何限制，如果有，则支持例程*不负责检查类型，管理器是。
支持程序必须能够处理传入类型，无论它是什么。
无论如何，它对p-compilation完全没有任何影响。然而，任何这一点都与VEE有关，有一件事是肯定的：你的代码被编译到x86并且它总是比x86等价物运行数百或数千个时间。
对于OP而言，它并不是无关紧要的。
我想也许matlab可能会更快但我只是没有提到它。这些人已经在非常低的水平上长时间调整他们的东西了。


     以下为原文

  > 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.
-SHAWN-