- 浏览: 989413 次
- 性别:
- 来自: 广州
-
最新评论
-
qingchuwudi:
有用,非常感谢!
erlang进程的优先级 -
zfjdiamond:
你好 这条命令 在那里输入??
你们有yum 我有LuaRocks -
simsunny22:
这个是在linux下运行的吧,在window下怎么运行escr ...
escript的高级特性 -
mozhenghua:
http://www.erlang.org/doc/apps/ ...
mnesia 分布协调的几个细节 -
fxltsbl:
A new record of 108000 HTTP req ...
Haproxy 1.4-dev2: barrier of 100k HTTP req/s crossed
LuaJIT's interpreter is fast, because:
•It's written in assembler.
•It keeps all important state in registers. No C compiler manages to do that on x86.
•It uses indirect threading (aka labeled goto in C).
•It has a very small I-cache footprint (the core of the interpreter fits in 6K).
•The parser generates a register-based bytecode.
•The bytecode is really a word-code (32 bit/ins) and designed for fast decoding.
•Bytecode decode and dispatch is heavily optimized for superscalar CPUs.
•The bytecode is type-specialized and patched on-the-fly.
•The dispatch table is patched to allow for debug hooks and trace recording. No need to check for these cases in the fast paths.
•It uses NaN tagging for object references. This allows unboxed FP numbers with a minimal cache footprint for stacks/arrays. FP stores are auto-tagging.
•It inlines all fast paths.
•It uses special calling conventions for built-ins (fast functions).
•Tons more tuning in the VM ... and the JIT compiler has it's own bag of tricks.
E.g. x=x+1 is turned into the ADDVN instruction. This means it's specialized for the 2nd operand to be a constant. Here's the x86 code (+ SSE2 enabled) for this instruction:
// Prologue for type ABC instructions (others have a zero prologue).
movzx ebp, ah Decode RC (split of RD)
movzx eax, al Decode RB (split of RD)
// The instruction itself.
cmp [edx+ebp*8+0x4], -13 Type check of [RB]
ja ->lj_vmeta_arith_vn
movsd xmm0, [edx+ebp*8] Load of [RB]
addsd xmm0, [edi+eax*8] Add to [RC]
movsd [edx+ecx*8], xmm0 Store in [RA]
// Standard epilogue: decode + dispatch the next instruction.
mov eax, [esi] Load next bytecode
movzx ecx, ah Decode RA
movzx ebp, al Decode opcode
add esi, 0x4 Increment PC
shr eax, 0x10 Decode RD
jmp [ebx+ebp*4] Dispatch to next instruction
Yes, that's all of it. I don't think you can do this with less instructions. This code reaches up to 2.5 ipc on a Core2 and takes 5-6 cycles (2 nanoseconds on a 3 GHz machine).
翻译opcode,将opcode翻译为machine instruction。
解释与翻译的界限有点模糊。
如果以是否进行native code generation来界定是编译还是解释,那么编译是做native code generation的,而解释不做。
如果以是否直接利用硬件支持来进行instruction dispatch来界定,那么编译后生成的代码是直接靠硬件来做instruction dispatch,而解释器是用自己写的代码来做。
但这些都不是特别的精确,到底界限在哪里我也没有见到过什么好的定义。总之从程度上说,趋近于解释执行的方式在得到运行结果前对程序预先做的分析和处理较少,而趋近于编译的方式正好相反,在得到运行结果前对程序做了较多的分析和处理。
这帖里的代码可以看到很明显的用于instruction dispatch的代码:
而如果是通过硬件支持直接做instruction dispatch的话,dispatch本身就是隐含在每条机器指令中的。
这个肯定是这样的. 提升的地方就是原来lua vm的dispatch代码下岗了, 等价的native code上岗了.
jit的用处就是产生更好的等价代码...
翻译opcode,将opcode翻译为machine instruction。
解释与翻译的界限有点模糊。
如果以是否进行native code generation来界定是编译还是解释,那么编译是做native code generation的,而解释不做。
如果以是否直接利用硬件支持来进行instruction dispatch来界定,那么编译后生成的代码是直接靠硬件来做instruction dispatch,而解释器是用自己写的代码来做。
但这些都不是特别的精确,到底界限在哪里我也没有见到过什么好的定义。总之从程度上说,趋近于解释执行的方式在得到运行结果前对程序预先做的分析和处理较少,而趋近于编译的方式正好相反,在得到运行结果前对程序做了较多的分析和处理。
这帖里的代码可以看到很明显的用于instruction dispatch的代码:
而如果是通过硬件支持直接做instruction dispatch的话,dispatch本身就是隐含在每条机器指令中的。
jit做什么的 不就是把lua opcode intepret成x86码吗 那你以为jit做什么的?
同样是翻译语言,有口译和书面译的区别;同样是执行程序,也有解释(interpret)与编译(compile)的区别。《虚拟机 系统与进程的通用平台》一书中指出一类加速虚拟机执行程序的方式就是“动态翻译”(dynamic translation),而在高级语言虚拟机中这一般就被叫做编译。
这帖中引用的资料确实只是讲了LuaJIT中的解释器部分。LuaJIT是混合执行模式的虚拟机,同时具有解释器与JIT编译器的部分。
你说的是翻译源码还是opcode?
jit做什么的 不就是把lua opcode intepret成x86码吗 那你以为jit做什么的?
这个就是个用汇编写的解释器,用c写就是一个大的switch case,用汇编写就是一个dispatch table。
jit做什么的 不就是把lua opcode intepret成x86码吗 那你以为jit做什么的?
同样是翻译语言,有口译和书面译的区别;同样是执行程序,也有解释(interpret)与编译(compile)的区别。《虚拟机 系统与进程的通用平台》一书中指出一类加速虚拟机执行程序的方式就是“动态翻译”(dynamic translation),而在高级语言虚拟机中这一般就被叫做编译。
这帖中引用的资料确实只是讲了LuaJIT中的解释器部分。LuaJIT是混合执行模式的虚拟机,同时具有解释器与JIT编译器的部分。
jit做什么的 不就是把lua opcode intepret成x86码吗 那你以为jit做什么的?
adaptive compilation跟trace compilation不是同一种概念。根据代码热的程度做不同程度优化的是adaptive compilation;以trace为单元(相对于其它编译单元,例如函数/方法为单元)来编译的是trace compilation ^_^
LuaJIT 1.x貌似没有用trace compiler,JIT编译的方式就是很常见的以函数为单位的。在2.0才开始转用trace compiler。用了trace compiler最有名的大概是TraceMonkey了吧,很多人都应该听说过这个;Android的Dalvik里的JIT也有用;其它一些研究性质的VM也有用,不过还不是很普及。
我记得1.x就有呀 根据代码的hot度 来加速的 不知道是不是叫 trace compiler, 时间长了 记得不太清楚了...
LuaJIT 1.x貌似没有用trace compiler,JIT编译的方式就是很常见的以函数为单位的。在2.0才开始转用trace compiler。用了trace compiler最有名的大概是TraceMonkey了吧,很多人都应该听说过这个;Android的Dalvik里的JIT也有用;其它一些研究性质的VM也有用,不过还不是很普及。
标为红色的那些在Strongtalk里也是如此。
Strongtalk中有自己实现的汇编器,其解释器是通过代码控制汇编器在启动VM时生成出来的,也可以认为是“用汇编写的”。
它也是用indirect-threading(或者说token-threading),跟LuaJIT 2不同的是它的指令的操作码是字节码(只占8位)。
Strongtalks的字节码是基于栈的指令集,但通过“栈顶缓存”优化(top-of-stack caching)它比基于寄存器版本的同类实现只慢一点(而占用的内存空间小一些)。
Strongtalk也用tagged pointer来直接在指针里存放小整数等对象的值,减少了GC的压力。
Strongtalk也对直接调用VM内部函数有优化。
而Strongtalk是1994年到1996年在做的,后来则演化进了HotSpot里,将一些Java用不到的动态特性去除了,解释器稍微简化了些并且更快了。这些都并不是特别新的技术了,不过除了几家大厂的JVM外,其它VM就在近两三年才开始慢慢跟上时代的步伐……
看看HotSpot的解释器的一张截图:http://rednaxelafx.iteye.com/picture/52954
也是非常简洁的……
LuaJIT比较新的部分是它的trace compiler。这种技术现在只在很少的VM中得到了应用。
另外:打个广告,之前在JavaEye开了个高级语言虚拟机的圈子,欢迎来讨论相关话题。这帖就很合适,哈哈~
•It's written in assembler.
•It keeps all important state in registers. No C compiler manages to do that on x86.
•It uses indirect threading (aka labeled goto in C).
•It has a very small I-cache footprint (the core of the interpreter fits in 6K).
•The parser generates a register-based bytecode.
•The bytecode is really a word-code (32 bit/ins) and designed for fast decoding.
•Bytecode decode and dispatch is heavily optimized for superscalar CPUs.
•The bytecode is type-specialized and patched on-the-fly.
•The dispatch table is patched to allow for debug hooks and trace recording. No need to check for these cases in the fast paths.
•It uses NaN tagging for object references. This allows unboxed FP numbers with a minimal cache footprint for stacks/arrays. FP stores are auto-tagging.
•It inlines all fast paths.
•It uses special calling conventions for built-ins (fast functions).
•Tons more tuning in the VM ... and the JIT compiler has it's own bag of tricks.
E.g. x=x+1 is turned into the ADDVN instruction. This means it's specialized for the 2nd operand to be a constant. Here's the x86 code (+ SSE2 enabled) for this instruction:
// Prologue for type ABC instructions (others have a zero prologue).
movzx ebp, ah Decode RC (split of RD)
movzx eax, al Decode RB (split of RD)
// The instruction itself.
cmp [edx+ebp*8+0x4], -13 Type check of [RB]
ja ->lj_vmeta_arith_vn
movsd xmm0, [edx+ebp*8] Load of [RB]
addsd xmm0, [edi+eax*8] Add to [RC]
movsd [edx+ecx*8], xmm0 Store in [RA]
// Standard epilogue: decode + dispatch the next instruction.
mov eax, [esi] Load next bytecode
movzx ecx, ah Decode RA
movzx ebp, al Decode opcode
add esi, 0x4 Increment PC
shr eax, 0x10 Decode RD
jmp [ebx+ebp*4] Dispatch to next instruction
Yes, that's all of it. I don't think you can do this with less instructions. This code reaches up to 2.5 ipc on a Core2 and takes 5-6 cycles (2 nanoseconds on a 3 GHz machine).
评论
17 楼
linkerlin
2010-04-15
Lua的软肋还是在GC上。
我上次和LuaJIT的开发者聊,他说,目前的Lua C API导致无法更新GC.
指针被暴露啊。GC没法改进成 拷贝分代GC.
我上次和LuaJIT的开发者聊,他说,目前的Lua C API导致无法更新GC.
指针被暴露啊。GC没法改进成 拷贝分代GC.
16 楼
mryufeng
2010-03-09
RednaxelaFX 写道
mryufeng 写道
你说的是翻译源码还是opcode?
翻译opcode,将opcode翻译为machine instruction。
解释与翻译的界限有点模糊。
如果以是否进行native code generation来界定是编译还是解释,那么编译是做native code generation的,而解释不做。
如果以是否直接利用硬件支持来进行instruction dispatch来界定,那么编译后生成的代码是直接靠硬件来做instruction dispatch,而解释器是用自己写的代码来做。
但这些都不是特别的精确,到底界限在哪里我也没有见到过什么好的定义。总之从程度上说,趋近于解释执行的方式在得到运行结果前对程序预先做的分析和处理较少,而趋近于编译的方式正好相反,在得到运行结果前对程序做了较多的分析和处理。
这帖里的代码可以看到很明显的用于instruction dispatch的代码:
jmp [ebx+ebp*4] Dispatch to next instruction
而如果是通过硬件支持直接做instruction dispatch的话,dispatch本身就是隐含在每条机器指令中的。
这个肯定是这样的. 提升的地方就是原来lua vm的dispatch代码下岗了, 等价的native code上岗了.
jit的用处就是产生更好的等价代码...
15 楼
RednaxelaFX
2010-03-09
mryufeng 写道
你说的是翻译源码还是opcode?
翻译opcode,将opcode翻译为machine instruction。
解释与翻译的界限有点模糊。
如果以是否进行native code generation来界定是编译还是解释,那么编译是做native code generation的,而解释不做。
如果以是否直接利用硬件支持来进行instruction dispatch来界定,那么编译后生成的代码是直接靠硬件来做instruction dispatch,而解释器是用自己写的代码来做。
但这些都不是特别的精确,到底界限在哪里我也没有见到过什么好的定义。总之从程度上说,趋近于解释执行的方式在得到运行结果前对程序预先做的分析和处理较少,而趋近于编译的方式正好相反,在得到运行结果前对程序做了较多的分析和处理。
这帖里的代码可以看到很明显的用于instruction dispatch的代码:
jmp [ebx+ebp*4] Dispatch to next instruction
而如果是通过硬件支持直接做instruction dispatch的话,dispatch本身就是隐含在每条机器指令中的。
14 楼
mryufeng
2010-03-09
RednaxelaFX 写道
mryufeng 写道
wkoffee 写道
好像通篇都是intepreter,没有jit什么事
jit做什么的 不就是把lua opcode intepret成x86码吗 那你以为jit做什么的?
同样是翻译语言,有口译和书面译的区别;同样是执行程序,也有解释(interpret)与编译(compile)的区别。《虚拟机 系统与进程的通用平台》一书中指出一类加速虚拟机执行程序的方式就是“动态翻译”(dynamic translation),而在高级语言虚拟机中这一般就被叫做编译。
这帖中引用的资料确实只是讲了LuaJIT中的解释器部分。LuaJIT是混合执行模式的虚拟机,同时具有解释器与JIT编译器的部分。
你说的是翻译源码还是opcode?
13 楼
wkoffee
2010-03-09
mryufeng 写道
wkoffee 写道
好像通篇都是intepreter,没有jit什么事
jit做什么的 不就是把lua opcode intepret成x86码吗 那你以为jit做什么的?
这个就是个用汇编写的解释器,用c写就是一个大的switch case,用汇编写就是一个dispatch table。
12 楼
RednaxelaFX
2010-03-09
mryufeng 写道
wkoffee 写道
好像通篇都是intepreter,没有jit什么事
jit做什么的 不就是把lua opcode intepret成x86码吗 那你以为jit做什么的?
同样是翻译语言,有口译和书面译的区别;同样是执行程序,也有解释(interpret)与编译(compile)的区别。《虚拟机 系统与进程的通用平台》一书中指出一类加速虚拟机执行程序的方式就是“动态翻译”(dynamic translation),而在高级语言虚拟机中这一般就被叫做编译。
这帖中引用的资料确实只是讲了LuaJIT中的解释器部分。LuaJIT是混合执行模式的虚拟机,同时具有解释器与JIT编译器的部分。
11 楼
mryufeng
2010-03-09
wkoffee 写道
好像通篇都是intepreter,没有jit什么事
jit做什么的 不就是把lua opcode intepret成x86码吗 那你以为jit做什么的?
10 楼
wkoffee
2010-03-09
好像通篇都是intepreter,没有jit什么事
9 楼
mryufeng
2010-03-08
多谢指教 跟你学了很多东西! 俺是你的粉丝哦...
8 楼
RednaxelaFX
2010-03-08
mryufeng 写道
我记得1.x就有呀 根据代码的hot度 来加速的 不知道是不是叫 trace compiler, 时间长了 记得不太清楚了...
adaptive compilation跟trace compilation不是同一种概念。根据代码热的程度做不同程度优化的是adaptive compilation;以trace为单元(相对于其它编译单元,例如函数/方法为单元)来编译的是trace compilation ^_^
7 楼
mryufeng
2010-03-08
RednaxelaFX 写道
mryufeng 写道
lua 1.x的时候就只有trace compiler技术是个亮点.印象最深的是dynasm. 2.0的变化太大了 一下子就爆发出来了...
LuaJIT 1.x貌似没有用trace compiler,JIT编译的方式就是很常见的以函数为单位的。在2.0才开始转用trace compiler。用了trace compiler最有名的大概是TraceMonkey了吧,很多人都应该听说过这个;Android的Dalvik里的JIT也有用;其它一些研究性质的VM也有用,不过还不是很普及。
我记得1.x就有呀 根据代码的hot度 来加速的 不知道是不是叫 trace compiler, 时间长了 记得不太清楚了...
6 楼
RednaxelaFX
2010-03-08
mryufeng 写道
lua 1.x的时候就只有trace compiler技术是个亮点.印象最深的是dynasm. 2.0的变化太大了 一下子就爆发出来了...
LuaJIT 1.x貌似没有用trace compiler,JIT编译的方式就是很常见的以函数为单位的。在2.0才开始转用trace compiler。用了trace compiler最有名的大概是TraceMonkey了吧,很多人都应该听说过这个;Android的Dalvik里的JIT也有用;其它一些研究性质的VM也有用,不过还不是很普及。
5 楼
mryufeng
2010-03-08
lua 1.x的时候就只有trace compiler技术是个亮点.印象最深的是dynasm. 2.0的变化太大了 一下子就爆发出来了...
4 楼
RednaxelaFX
2010-03-08
啊,上面码字的时候被打了个岔写漏了……我是想说标记为红色的是Strongtalk与HotSpot也有的特性,而绿色的是Strongtalk中存在但HotSpot中没有的特性——因为Java(早期被认为)不需要tagged pointer
3 楼
RednaxelaFX
2010-03-08
mryufeng 写道
LuaJIT's interpreter is fast, because:
•It's written in assembler.
•It keeps all important state in registers. No C compiler manages to do that on x86.
•It uses indirect threading (aka labeled goto in C).
•It has a very small I-cache footprint (the core of the interpreter fits in 6K).
•The parser generates a register-based bytecode.
•The bytecode is really a word-code (32 bit/ins) and designed for fast decoding.
•Bytecode decode and dispatch is heavily optimized for superscalar CPUs.
•The bytecode is type-specialized and patched on-the-fly.
•The dispatch table is patched to allow for debug hooks and trace recording. No need to check for these cases in the fast paths.
•It uses NaN tagging for object references. This allows unboxed FP numbers with a minimal cache footprint for stacks/arrays. FP stores are auto-tagging.
•It inlines all fast paths.
•It uses special calling conventions for built-ins (fast functions).
•Tons more tuning in the VM ... and the JIT compiler has it's own bag of tricks.
•It's written in assembler.
•It keeps all important state in registers. No C compiler manages to do that on x86.
•It uses indirect threading (aka labeled goto in C).
•It has a very small I-cache footprint (the core of the interpreter fits in 6K).
•The parser generates a register-based bytecode.
•The bytecode is really a word-code (32 bit/ins) and designed for fast decoding.
•Bytecode decode and dispatch is heavily optimized for superscalar CPUs.
•The bytecode is type-specialized and patched on-the-fly.
•The dispatch table is patched to allow for debug hooks and trace recording. No need to check for these cases in the fast paths.
•It uses NaN tagging for object references. This allows unboxed FP numbers with a minimal cache footprint for stacks/arrays. FP stores are auto-tagging.
•It inlines all fast paths.
•It uses special calling conventions for built-ins (fast functions).
•Tons more tuning in the VM ... and the JIT compiler has it's own bag of tricks.
标为红色的那些在Strongtalk里也是如此。
Strongtalk中有自己实现的汇编器,其解释器是通过代码控制汇编器在启动VM时生成出来的,也可以认为是“用汇编写的”。
它也是用indirect-threading(或者说token-threading),跟LuaJIT 2不同的是它的指令的操作码是字节码(只占8位)。
Strongtalks的字节码是基于栈的指令集,但通过“栈顶缓存”优化(top-of-stack caching)它比基于寄存器版本的同类实现只慢一点(而占用的内存空间小一些)。
Strongtalk也用tagged pointer来直接在指针里存放小整数等对象的值,减少了GC的压力。
Strongtalk也对直接调用VM内部函数有优化。
而Strongtalk是1994年到1996年在做的,后来则演化进了HotSpot里,将一些Java用不到的动态特性去除了,解释器稍微简化了些并且更快了。这些都并不是特别新的技术了,不过除了几家大厂的JVM外,其它VM就在近两三年才开始慢慢跟上时代的步伐……
看看HotSpot的解释器的一张截图:http://rednaxelafx.iteye.com/picture/52954
也是非常简洁的……
LuaJIT比较新的部分是它的trace compiler。这种技术现在只在很少的VM中得到了应用。
另外:打个广告,之前在JavaEye开了个高级语言虚拟机的圈子,欢迎来讨论相关话题。这帖就很合适,哈哈~
2 楼
dennis_zane
2010-03-08
高科技,太牛了
1 楼
mryufeng
2010-03-08
真牛B的技术!!!
发表评论
-
lua源码研究阅读顺序
2009-11-25 14:27 5066转自:http://www.reddit.com/commen ... -
《Beginning Lua Programming》新鲜出炉
2009-02-10 14:52 2600老朱同学给我的: 《Beginning Lua Program ... -
Lua三人帮出新书 Lua Programming Gems
2008-12-22 14:37 4834http://www.lua.org/gems/ We ar ... -
tail程序 c版本和lua版本大比拼
2008-08-10 00:44 7004闲来的时候做了个tail 程序,和*nix下的tail功能一样 ... -
lua扩展模块里面如何申请内存
2008-07-25 12:35 5429我们在编写lua模块的时候经常会遇到申请内存的情况,有2中用途 ... -
未公开的Lua Frontier Pattern %f 比较实用
2008-07-23 17:57 5141参见: http://lua-users.org/wiki/F ... -
Notes about how the Lua garbage collector works
2008-07-22 00:46 4627lua垃圾收集的原理 参见: http://lua-users ... -
Yueliang + LuLu 完整的LuaInLua系统
2008-07-21 11:43 4664Yueliang: http://yueliang.luafo ... -
luatcc 方便你写lua扩展
2008-07-18 22:21 6825当要用c实现lua的模块的时候 就涉及到模块的编译 调试 运 ... -
luacoco 增强lua的coroutine功能
2008-07-04 16:41 6155Coco is a small extension to ge ... -
lua做tcp服务器的2套库
2008-07-04 15:37 6374copas是纯lua的实现 依赖于luasocket, 但是毕 ... -
lua symbexec的2个用途
2008-07-04 11:40 4468原型: static Instruction symbexec ... -
lua coroutine是如何实现的?
2008-07-03 12:47 14245一直对coroutine的运作原理不是很明白, 这几天琢磨了下 ... -
RemDebug小巧的Lua远端调试器 告诉你coroutine很强大
2008-06-30 14:47 7535RemDebug is a remote debugger f ... -
Lua For Windows v5.1.3.11 Release Candidate 1
2008-06-30 11:41 5444Lua For Windows v5.1.3.11 Relea ... -
Alien - Pure Lua extensions
2008-06-27 02:19 4495What is Alien Alien is a Forei ... -
luaedit 新版本 支持lua5.1 马上要发布
2008-06-27 01:53 5036Announcing LuaEdit 2008 and new ... -
lua newproxy用途
2008-06-27 01:02 5923What does newproxy() in 5.1? & ... -
你们有yum 我有LuaRocks
2008-06-26 21:38 7948LuaRocks This is LuaRocks, a d ... -
LPeg Parsing Expression Grammars For Lua, version
2008-06-16 12:05 5546Introduction LPeg is a new pat ...
相关推荐
在日常的开发和使用中,我们经常需要借助各种小工具来提高工作效率,例如快速启动常用的应用程序、管理文件等。一个简单但功能强大的集成工具箱可以帮助用户快速访问、启动并管理程序。今天,我们将以Python为基础,结合Tkinter和Win32API,开发一个类似Windows快捷方式的工具箱应用,能够让你轻松集成各种常用程序并一键启动
django自建博客app
《基于YOLOv8的智慧校园实验室高压灭菌锅安全联锁系统》(包含源码、可视化界面、完整数据集、部署教程)简单部署即可运行。功能完善、操作简单,适合毕设或课程设计
用于hifi测序数据的基因组组装程序
Microsoft Access 2010 数据库引擎可再发行程序包AccessDatabaseEngine-X64解压后的文件AceRedist
从大模型、智能体到复杂AI应用系统的构建——以产业大脑为例
自然语言处理之TF-IDF算法与TextRank算法的缠绵_textrank,tf-idf和两者的组合-CSDN博客.html
内容概要:2023版《科学智能 (AI4S)全球发展观察与展望》阐述了AI for Science(AI4S)在全球范围内的最新进展及其对科学和工业的深远影响。文章首先回顾了AI4S在过去一年中的快速发展,特别是在药物研发、材料科学、地质学、污染治理等多个领域的应用实例。AI4S通过结合深度学习、机器学习和其他AI技术,加速了从基础研究到实际应用的转化过程。例如,在药物研发中,AI4S帮助科学家克服了“反摩尔定律”的挑战,提高了新药研发的成功率;在材料科学中,AI4S实现了复杂材料的高效模拟,如人造钻石、石墨烯、碳纳米管等;在地质学中,AI4S通过模拟地球内部结构和物理过程,为地震学研究提供了新视角。此外,文章还探讨了大语言模型(LLMs)与科学方法的结合,指出LLMs不仅能辅助科学研究,还能生成新的科学假设并进行逻辑推理。 适合人群:具备一定科研背景或对AI技术感兴趣的科研人员、工程师、政策制定者及高校师生。
这个数据集包含了日常步数统计、睡眠时长、活跃分钟数以及消耗的卡路里,是个人健康与健身追踪的一部分。 该数据集非常适合用于以下实践: 数据清洗:现实世界中的数据往往包含缺失值、异常值或不一致之处。例如,某些天的步数可能缺失,或者存在不切实际的数值(如10,000小时的睡眠或负数的卡路里消耗)。通过处理这些问题,可以学习如何清理和准备数据进行分析。 探索性分析(发现日常习惯中的模式):可以通过分析找出日常生活中的模式和趋势,比如一周中哪一天人们通常走得最多,或是睡眠时间与活跃程度之间的关系等。 构建可视化图表(步数趋势、睡眠与活动对比图):将数据转换成易于理解的图形形式,有助于更直观地看出数据的趋势和关联。例如,绘制步数随时间变化的趋势图,或是比较睡眠时间和活动量之间的关系图。 数据叙事(将个人风格的追踪转化为可操作的见解):通过讲述故事的方式,把从数据中得到的洞察变成具体的行动建议。例如,根据某人特定时间段内的活动水平和睡眠质量,提供改善健康状况的具体建议。
框架结构天城商业办公楼5200平米(建筑图 结构图 计算书 开题报告 任务书 文献翻.zip
柴油机连杆加工工艺及夹具设计.zip
读书网首页的HTML信息
文字渐变颜色代码生成器:让文字绽放多彩魅力,演示:在信息交流日益丰富的今天,个性化的文字展示成为吸引目光的关键。这款文字渐变颜色代码生成器,便是为满足这一需求而生的绿色软件,无需安装,便捷实用。 它的操作极为简便。用户只需在软件界面中输入想要转换的文字内容,接着从丰富的色彩选项里挑选心仪的起始颜色与结束颜色,随后轻轻按下 “转换按钮”,神奇的事情就此发生 —— 适用于论坛、网页、QQ 空间等多种平台,以及自定义格式的渐变颜色代码便会即刻生成。不仅如此,生成的代码还能自动复制到剪切板,极大地节省了用户手动复制的时间。当你在论坛回帖、更新网页内容或是装扮 QQ 空间时,只需轻松粘贴代码,原本单调的文字瞬间就能拥有绚丽的渐变色彩,瞬间脱颖而出,为你的表达增添独特魅力,让文字不再平凡,轻松成为视觉焦点。 一款可以轻松把一段文字生成渐变颜色代码的绿色软件,当你在软件中输入完要转换的文字后,只需要挑选自己喜欢的起始颜色、结束颜色后,按一下―转换按钮即可生成相应的论坛/网页/QQ空间以及自定义格式代码,并且代码可以自动复制到剪切板中,回帖时直接粘贴代码即可不错得文字代码生成器,让你得文字更加漂亮.
1.【锂电池剩余寿命预测】Transformer锂电池剩余寿命预测(Matlab完整源码和数据) 2.数据集:NASA数据集,已经处理好,B0005电池训练、B0006测试; 3.环境准备:Matlab2023b,可读性强; 4.模型描述:Transformer在各种各样的问题上表现非常出色,现在被广泛使用。 5.领域描述:近年来,随着锂离子电池的能量密度、功率密度逐渐提升,其安全性能与剩余使用寿命预测变得愈发重要。本代码实现了Transformer在该领域的应用。 6.作者介绍:机器学习之心,博客专家认证,机器学习领域创作者,2023博客之星TOP50,主做机器学习和深度学习时序、回归、分类、聚类和降维等程序设计和案例分析,文章底部有博主联系方式。从事Matlab、Python算法仿真工作8年,更多仿真源码、数据集定制私信。
资源内项目源码是来自个人的毕业设计,代码都测试ok,包含源码、数据集、可视化页面和部署说明,可产生核心指标曲线图、混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果、标签分布图。都是运行成功后才上传资源,毕设答辩评审绝对信服的保底85分以上,放心下载使用,拿来就能用。包含源码、数据集、可视化页面和部署说明一站式服务,拿来就能用的绝对好资源!!! 项目备注 1、该资源内项目代码都经过测试运行成功,功能ok的情况下才上传的,请放心下载使用! 2、本项目适合计算机相关专业(如计科、人工智能、通信工程、自动化、电子信息等)的在校学生、老师或者企业员工下载学习,也适合小白学习进阶,当然也可作为毕设项目、课程设计、大作业、项目初期立项演示等。 3、如果基础还行,也可在此代码基础上进行修改,以实现其他功能,也可用于毕设、课设、作业等。 下载后请首先打开README.txt文件,仅供学习参考, 切勿用于商业用途。
资源内项目源码是来自个人的毕业设计,代码都测试ok,包含源码、数据集、可视化页面和部署说明,可产生核心指标曲线图、混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果、标签分布图。都是运行成功后才上传资源,毕设答辩评审绝对信服的保底85分以上,放心下载使用,拿来就能用。包含源码、数据集、可视化页面和部署说明一站式服务,拿来就能用的绝对好资源!!! 项目备注 1、该资源内项目代码都经过测试运行成功,功能ok的情况下才上传的,请放心下载使用! 2、本项目适合计算机相关专业(如计科、人工智能、通信工程、自动化、电子信息等)的在校学生、老师或者企业员工下载学习,也适合小白学习进阶,当然也可作为毕设项目、课程设计、大作业、项目初期立项演示等。 3、如果基础还行,也可在此代码基础上进行修改,以实现其他功能,也可用于毕设、课设、作业等。 下载后请首先打开README.txt文件,仅供学习参考, 切勿用于商业用途。
Android项目原生java语言课程设计,包含LW+ppt
配套文章:https://blog.csdn.net/gust2013/article/details/146909670?spm=1001.2014.3001.5502
《基于YOLOv8的智慧社区儿童游乐设施安全监测系统》(包含源码、可视化界面、完整数据集、部署教程)简单部署即可运行。功能完善、操作简单,适合毕设或课程设计