有没有人尝试这样的东西加速程序？ [英] Has anyone tried something like this to speed up programs?

问题描述

你好，


这是一个我一直在努力加速程序的想法，但是

仍然保持便携性。这只是一个非常简单粗略的描述

，因为我还没有弄清楚细节。


该程序将包含许多小实用程序这些功能可以实现少量的工作。这些都不会实际运行。相反，

它们将被作为字符串进行类型转换，并且程序将检查这些字符串

。换句话说，该程序将检查自己的代码。

通过对这些表现良好的函数执行此操作，程序

将尝试推断出有关机器的基本事实

的代码运行它的机器。然后程序将使用这些知识来实时编写新的机器代码，将其作为一个函数进行类型转换并运行它，这是一种便携式自我重写代码。实现便携性

和速度。 （当然最初的扣除需要时间，所以这个

只有在程序的实际主要目的

对时间非常敏感时才真正有用）


有没有人知道这样的事情，如果是的话，有没有人知道

哪里可以找到有关它的信息？


谢谢，你们摇滚！

Hello,

Here is an idea I''ve been toying with to speed up programs but
still keep them portable. It''s just a very handwavey rough description
right now since I haven''t worked out details.

The program would contain lots of little utility functions which do
small amounts of work. None of these would actually be run. Rather,
they would be typecast as strings and those strings would be examined
by the program. In otherwords, the program would examine its own code.
By doing this to these little well-behaved functions, the program
would attempt to deduce the rudimentary facts about the machine code of
the machine running it. The program would then use this knowledge to
write new machine code on the fly, typecast it as a function and run
it, a sort of portable self-rewriting code to achieve both portability
and speed. (Of course the initial deductions would take time, so this
would only really be useful if the actual main purpose of the program
was extremely time sensitive)

Does anyone know of anything like this, and if so, does anyone know
where I can find info about it?

Thanks, you guys rock!

推荐答案

2006年5月24日21:08:41 -0700，Snis Pilbor < sn ******** @ yahoo.com>

在comp.lang.c中写道：

On 24 May 2006 21:08:41 -0700, "Snis Pilbor" <sn********@yahoo.com>
wrote in comp.lang.c:

你好，

这是一个我一直在努力加速程序的想法，但
仍然保持便携性。这只是一个非常简单粗略的描述
因为我还没有弄清楚细节。

该程序将包含许多小实用功能，这些功能很小
工作量。这些都不会实际运行。相反，
它们将被强制转换为字符串，并且这些字符串将被检查


这里你已经离开了C语言。除了调用它之外，C语言无法使用函数执行任何操作或

取其地址。没有定义的方法将函数

转换为字符串，或检查函数的内容。

程序。换句话说，程序将检查自己的代码。


再次，C中没有定义这样的东西。

通过对这些表现良好的函数执行此操作，程序将尝试推断出运行它的机器的机器代码的基本事实。然后程序将使用这些知识来动态编写新的机器代码，将其作为一个函数进行类型转换并运行它，这是一种便携式自编码代码，以实现可移植性和速度。 （当然最初的扣除需要时间，所以这个
只有在程序的实际主要目的对时间非常敏感时才真正有用）


在这里，程序很可能将字节写入形成一系列机器代码指令的

缓冲区，在C中没有定义的方式来定义该序列作为一个函数。


忘了这一点，因为这可能是为了在某些平台/编译器上做你想做的事情，所以有一个事实有些运行

系统的安全功能不允许这样做。应用程序

在用户执行，而不是系统，模式无法写入内存

包含可执行文件的机器代码，并且无法传输控件

到他们可以写入的任何内存。我认为即使是64位Windows也有这个安全性。

有没有人知道这样的事情，如果有的话，有谁知道
我在哪里可以找到关于它的信息？

谢谢，你们摇滚！

Hello,

Here is an idea I''ve been toying with to speed up programs but
still keep them portable. It''s just a very handwavey rough description
right now since I haven''t worked out details.

The program would contain lots of little utility functions which do
small amounts of work. None of these would actually be run. Rather,
they would be typecast as strings and those strings would be examined
Here you''ve already left the C language behind. There is no way in
the C language to do anything with a function other than to call it or
take its address. There is no defined way at all to cast a function
to a string, or to examine the contents of a function.
by the program. In otherwords, the program would examine its own code.
Again, no such thing is defined in C.
By doing this to these little well-behaved functions, the program
would attempt to deduce the rudimentary facts about the machine code of
the machine running it. The program would then use this knowledge to
write new machine code on the fly, typecast it as a function and run
it, a sort of portable self-rewriting code to achieve both portability
and speed. (Of course the initial deductions would take time, so this
would only really be useful if the actual main purpose of the program
was extremely time sensitive)
Here again, it is quite possible for a program to write bytes into a
buffer that form a sequence of machine code instructions, there is no
defined way in C to call that sequence as a function.

Forgetting that, because this can probably be made to do what you want
on some platforms/compilers, there is the fact that some operating
systems have security features that would not allow this. Applications
executing in user, as opposed to system, mode cannot write to memory
containing the executable''s machine code, and can''t transfer control
to any memory they can write to. I think that even 64-bit Windows has
this security.
Does anyone know of anything like this, and if so, does anyone know
where I can find info about it?

Thanks, you guys rock!

除了这个是偏离主题的事实，由于事实它在标准C中都是未定义的，它似乎没有意义，至少对我来说是b $ b。因此，让我们来看看为什么会给我这样的印象：


可执行映像在某些操作系统的某些硬件架构上运行。它必须首先使用一些工具集为这个

处理器/ OS组合构建。


当你构建代码时，你知道程序

本身可以通过检查它自己的机器代码来学习。因此，在运行时可以通过如此复杂的技巧实现任何

优化，也可以在构建时实现，可能还有预处理器

条件为特定的处理器/操作系统组合定义符号上的某些优化序列

。


我要在这里解释Knuth，虽然我怀疑我的版本是

足够聪明，可以像往常一样经常被引用：


过于雄心勃勃的优化是所有邪恶的平方根（或者在<在节目编排中，它是最少的大部分。


-

Jack Klein

： http://JK-Technology.Com

常见问题解答

comp.lang.c http://c-faq.com/

comp.lang.c ++ HTTP：// WWW。 parashift.com/c++-faq-lite/

alt.comp.lang.learn.c-c ++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc .html

Aside from the fact that this is off-topic, due to the fact that it is
all undefined in standard C, it doesn''t seem to make sense, at least
to me. So let''s look at why I get that impression:

The executable image is running on some hardware architecture under
some operating system. It had to be built with some tool set for that
processor/OS combination in the first place.

At the time you built the code, you know everything that the program
itself can learn from examining it''s own machine code. So any
optimizations that it could achieve by such convoluted tricks at run
time could also be achieved at build time, possibly with preprocessor
conditionals to select certain optimized sequences on symbols defined
for the specific processor/OS combination.

I''m going to paraphrase Knuth here, although I doubt my version is
clever enough to ever be quoted as often as the original:

"Overly ambitious optimization is the square root of all evil (or at
least most of it) in programming."

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

Snis Pilboraécrit：

Snis Pilbor a écrit :

你好，

这是一个想法我'一直在努力加速计划，但
仍然保持便携。这只是一个非常简单粗略的描述
因为我还没有弄清楚细节。

该程序将包含许多小实用功能，这些功能很小
工作量。这些都不会实际运行。相反，
它们将被作为字符串进行类型转换，并且程序将检查这些字符串。


在C中你不需要对字符串进行类型转换。只需直接使用普通函数

指针。


换句话说，程序会检查自己的代码。
通过这样做对这些小问题 - 行为功能，程序将试图推断出运行它的机器的机器代码的基本事实。


运行它的机器的机器代码。嗯，你的意思是硬件

运行吗？或运行它的硬件的微代码？

然后程序将使用这些知识来动态编写新的机器代码，将其作为一个函数进行类型转换并运行它，一种便携式自我重写代码，以实现便携性和速度。


我写了一个JIT（Just In Time编译器），动态地执行
代码生成但是没有，它不关心什么类型的模型CPU

是。它生成可跨模型移植的代码，或为特定型号的CPU生成

代码但是，这是静态完成的，

不是动态的。我敢打赌，你会花很多时间做这些测试，确保收益无关


（当然，最初的扣款需要时间，所以这会只有当程序的实际主要目的对时间非常敏感时才真正有用。


嗯，我打赌只是为了测量程序运行的速度你需要什么？ />
至少几毫秒。然后你必须进行几次测试

，所以你最终会损失至少一秒钟这个


加速比应该更多第二个三角洲，非常壮观。

有没有人知道这样的事情，如果有的话，有谁知道
我在哪里可以找到有关它的信息？

Hello,

Here is an idea I''ve been toying with to speed up programs but
still keep them portable. It''s just a very handwavey rough description
right now since I haven''t worked out details.

The program would contain lots of little utility functions which do
small amounts of work. None of these would actually be run. Rather,
they would be typecast as strings and those strings would be examined
by the program.
In C you do not need to typecast to string. Just use plain function
pointers directly.

In otherwords, the program would examine its own code.
By doing this to these little well-behaved functions, the program
would attempt to deduce the rudimentary facts about the machine code of
the machine running it.
The "machine code of the machine running it". Mmm you mean the hardware
running it? Or the microcode of the hardware running it?
The program would then use this knowledge to
write new machine code on the fly, typecast it as a function and run
it, a sort of portable self-rewriting code to achieve both portability
and speed.
I have written a JIT (Just In Time compiler) that does dynamically
code generation but no, it does not care what type of model the CPU
is. It generates code that is portable across models, or generates
code for a specific model of CPU but then, that is done statically,
not dynamically. I bet you would loose so much time doing those
tests that the gains would be nothing

(Of course the initial deductions would take time, so this would only really be useful if the actual main purpose of the program
was extremely time sensitive)

Well, I bet just to MEASURE how fast a program runs you would need
some milli-seconds at least. THEN you have to run several tests
of that, so you will end up lossing at least a second for this

The speedup should be much more than a second delta, quite a feat.
Does anyone know of anything like this, and if so, does anyone know
where I can find info about it?

据我所知，没有人做过这样的事情。

As far as I know, nobody has done something like this.

>这是一个我一直在努力加速程序的想法，但

> Here is an idea I''ve been toying with to speed up programs but

仍然保持便携性。这只是一个非常简单粗略的描述
因为我还没有弄清楚细节。

该程序将包含许多小实用功能，这些功能很小
工作量。这些都不会实际运行。相反，
它们将被强制转换为字符串，并且将检查这些字符串


由于nul终结符在字符串中的作用和常见的存在
$ b机器码中该字节的$ b，我建议你不要使用

" strings"，而是内存块。

程序。换句话说，程序将检查自己的代码。


你在这里假设程序学习汇编语言

它运行的机器，然后弄清楚如何生成

快速代码，没有事先了解

机器代码的结构或它正在运行的目标机器？我认为

这将花费*至少* b * b
编译GCC所需时间的10倍。实际上我认为打败一个试图学习它的第一语言的人类会有困难。

通过对这些表现良好的函数执行此操作，程序
会尝试推断出运行它的机器的机器代码的基本事实。然后程序将使用这些知识来动态编写新的机器代码，将其作为一个函数进行类型转换并运行它，这是一种便携式自编码代码，以实现可移植性和速度。 （当然最初的扣除需要时间，所以这个
只有在程序的实际主要目的对时间非常敏感时才真正有用）


我不得不怀疑从头开始培养一些人类程序员是否会更快。你还需要一些机制来节省

的扣除额，这样下次启动代码就不用多年了。

有没有人知道类似的东西这个，如果有的话，有没有人知道
我在哪里可以找到它的信息？

still keep them portable. It''s just a very handwavey rough description
right now since I haven''t worked out details.

The program would contain lots of little utility functions which do
small amounts of work. None of these would actually be run. Rather,
they would be typecast as strings and those strings would be examined
Due to the role of the nul terminator in strings and the common presence
of that byte in machine code, I suggest you don''t literally use
"strings", but blocks of memory.
by the program. In otherwords, the program would examine its own code.
Are you assuming here that the program learns the assembly language
of the machine it is running on, and then figures out how to generate
fast code from that, with no prior knowledge of the structure of
machine code or what target machine it''s running on? I would assume
that this would take *at least* 10 times the time necessary to
compile GCC. Actually I think it would have trouble beating a human
infant trying to learn its first language.
By doing this to these little well-behaved functions, the program
would attempt to deduce the rudimentary facts about the machine code of
the machine running it. The program would then use this knowledge to
write new machine code on the fly, typecast it as a function and run
it, a sort of portable self-rewriting code to achieve both portability
and speed. (Of course the initial deductions would take time, so this
would only really be useful if the actual main purpose of the program
was extremely time sensitive)
I have to wonder if it would be faster to breed some human programmers
from scratch. You''d also need some mechanisms for it to SAVE the
deductions so the next startup of the code wouldn''t take years.
Does anyone know of anything like this, and if so, does anyone know
where I can find info about it?

如果你能在毫秒内让这个东西工作，它会似乎

如果目标机器

代码有一些非常有趣的应用程序是一种人类语言（或加密语言）。


Gordon L. Burditt

If you can get this thing to work in milliseconds, it would seem
to have some very interesting applications if the "target machine
code" was a human language (or an encrypted one).

Gordon L. Burditt

这篇关于有没有人尝试这样的东西加速程序？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！