C++实现的简单Map为什么比Java慢？深入分析JIT和AOT编译策略

已于 2024-12-18 18:21:46 修改
阅读量863 收藏 19
点赞数 10
文章标签： 开发语言 java c++ 数据结构 算法
于 2024-12-18 18:19:55 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/weixin_61470881/article/details/144566309
版权

研究目标

探究即时编译(JIT)和预先编译(AOT)策略之间的性能差异，以及理解它们各自的优势和劣势。需要强调的是，本研究的目的不是为了证明某种语言比另一种更慢或更差。

测试结果概述

在我们的测试中，我们观察到：

  • 使用JIT编译的HotSpot JVM 23（使用JVMCI和C2）表现最好
  • 使用Clang 18编译的C++版本
  • 使用native-image编译的GraalVM 23
  • 使用-Xcomp标志的HotSpot JVM 23（JVMCI和C2）
    这三种情况的性能都相对较慢。我们希望理解这种现象背后的原因，并找到可能的方法来提升C++版本的性能，使其能够匹配Java的JIT编译结果。

基准测试设计

我们的基准测试包括比较Java和C++中完全相同的简单哈希表（map）实现。我们确保两种实现在代码层面上是完全对应的（逐行对应）。这里需要说明的是，我们不是在比较标准库的哈希表实现（java.util.HashMap和std::unordered_map），因为它们的源代码实现本来就不等价。

测试参数设置：

  • 哈希表容量：20,000个桶
  • 插入对象数量：2,000,000个
  • 测试流程：先插入一次，清空map后再插入一次

这样设计的目的是为了利用哈希表的内部对象池机制：

  • 第一次插入时，对象会在堆上分配
  • 第二次插入时，对象会从内部对象池中重用

性能测试结果

HotSpot JVM（使用Graal JVMCI JIT）

PUT => 平均: 371 ns | 最小: 28 ns | 99.9% = [平均: 367 ns, 最大: 1.743 微秒]
PUT => 平均: 613 ns | 最小: 27 ns | 99.9% = [平均: 606 ns, 最大: 2.184 微秒]
GET => 平均: 615 ns | 最小: 14 ns | 99.9% = [平均: 607 ns, 最大: 2.549 微秒]
DEL => 平均: 662 ns | 最小: 18 ns | 99.9% = [平均: 658 ns, 最大: 2.538 微秒]

HotSpot JVM（使用C2 JIT）

PUT => 平均: 342 ns | 最小: 29 ns | 99.9% = [平均: 338 ns, 最大: 1.661 微秒]
PUT => 平均: 596 ns | 最小: 28 ns | 99.9% = [平均: 589 ns, 最大: 2.161 微秒]
GET => 平均: 599 ns | 最小: 20 ns | 99.9% = [平均: 592 ns, 最大: 2.275 微秒]
DEL => 平均: 826 ns | 最小: 23 ns | 99.9% = [平均: 817 ns, 最大: 3.420 微秒]

C++ LLVM（clang）

PUT => 平均: 726 ns | 最小: 30 ns | 99.9% = [平均: 720 ns, 最大: 4.097 微秒]
PUT => 平均: 857 ns | 最小: 18 ns | 99.9% = [平均: 848 ns, 最大: 2.933 微秒]
GET => 平均: 874 ns | 最小: 18 ns | 99.9% = [平均: 865 ns, 最大: 3.010 微秒]
DEL => 平均: 875 ns | 最小: 19 ns | 99.9% = [平均: 871 ns, 最大: 2.810 微秒]

GraalVM（native-image）

PUT => 平均: 190 ns | 最小: 21 ns | 99.9% = [平均: 183 ns, 最大: 814 ns]
PUT => 平均: 659 ns | 最小: 23 ns | 99.9% = [平均: 656 ns, 最大: 2.762 微秒]
GET => 平均: 399 ns | 最小: 21 ns | 99.9% = [平均: 396 ns, 最大: 2.124 微秒]
DEL => 平均: 323 ns | 最小: 27 ns | 99.9% = [平均: 321 ns, 最大: 1.850 微秒]

性能分析与优化建议

关键发现

  1. C++版本在第二次PUT操作中仍然比Java慢，这一点特别值得注意，因为此时所有对象都应该从对象池中获取，不涉及新的内存分配。

  2. 通过分析机器码，我们发现：

    • 主循环都是链表的线性搜索
    • Java使用32位压缩引用，而C++使用原生指针
    • 即使使用clang++ -O3 ... -m32编译成32位代码，C++版本仍然较慢
    • Java对象至少24字节，而不是仅仅12字节（2个引用+一个int）

  3. 性能差异可能与以下因素有关：

    • 内存分配模式
    • 缓存未命中
    • Java在循环内执行更多的机器指令
    • Java需要将32位值左移3位转换为指针

优化方向

  1. 自定义分配器：评论中提到，C++的主要改进点可能在于为哈希表内部的Entry对象使用自定义分配器。Java在堆上分配对象的速度可能比C++的new关键字更快，这个差距可以通过自定义分配器来弥补。

  2. 内存布局优化：考虑改进数据结构的内存布局，提高缓存利用率。

  3. 编译器优化：探索更多的Clang优化选项，特别是针对指针操作和内存访问模式的优化。

测试环境

操作系统：Ubuntu 18.04.6 LTS
处理器：Intel(R) Xeon(R) E-2288G CPU @ 3.70GHz
架构：x86_64

编译器版本：
- clang++ 18.1.0
- Java 23.0.1 (Oracle GraalVM)
- native-image 23.0.1

编译命令

C++代码编译

rm -f target/cpp/int_map_benchmark target/cpp/int_map.o target/cpp/bench.o target/cpp/int_map_benchmark.o
mkdir -p target/cpp
clang++ -Ofast -march=native -flto -std=c++17 -I./src/main/c -c ./src/main/c/int_map.cpp -o ./target/cpp/int_map.o
clang++ -Ofast -march=native -flto -std=c++17 -I./src/main/c -c ./src/main/c/bench.cpp -o ./target/cpp/bench.o
clang++ -Ofast -march=native -flto -std=c++17 -I./src/main/c -c ./src/main/c/int_map_benchmark.cpp -o ./target/cpp/int_map_benchmark.o
clang++ -Ofast -march=native -flto -std=c++17 -o ./target/cpp/int_map_benchmark ./target/cpp/int_map.o ./target/cpp/bench.o ./target/cpp/int_map_benchmark.o

运行命令

#!/bin/bash
WARMUP=${1:-0}
MEASUREMENTS=${2:-2000000}
CAPACITY=${3:-20000}
./target/cpp/int_map_benchmark $WARMUP $MEASUREMENTS $CAPACITY

完整代码实现

bench.hpp

#ifndef BENCH_HPP
#define BENCH_HPP

#include <chrono>
#include <iostream>
#include <limits>
#include <iomanip>
#include <string>
#include <cmath>
#include <map>
#include <sstream>

class Bench {
public:
    Bench(int warmupCount = 0);
    ~Bench();

    void mark();
    void measure();
    bool measure(long long);
    void reset();
    void reset(bool);
    void printResults() const;
    void printResults(bool) const;
    bool isWarmingUp() const;
    int getIterations() const;
    int getMeasurements() const;
    double getAverage() const;

private:
    int warmupCount;
    int measurementCount;
    long long sum;
    long long minTime;
    long long maxTime;
    int size;
    std::map<long long, long long>* results;
    std::chrono::steady_clock::time_point startTime;
    
    static std::string formatWithCommas(long long value);
    static std::pair<double, std::string> formatTime(double nanos);
    static std::string formatPercentage(double perc);
    static double roundToDecimals(double d, int decimals);
    void printPercentiles() const;
    void addPercentile(double perc) const;
    double avg() const;
};

#endif // BENCH_HPP

bench.cpp

#include "bench.hpp"
using namespace std;

Bench::Bench(int warmupCount)
    : warmupCount(warmupCount),
      measurementCount(0),
      sum(0),
      minTime(numeric_limits<long long>::max()),
      maxTime(numeric_limits<long long>::min()),
      size(0) {

        results = new map<long long, long long>();

}

Bench::~Bench() {
    delete results;
}

void Bench::mark() {
    startTime = chrono::steady_clock::now();
}

void Bench::measure() {
    auto endTime = chrono::steady_clock::now();
    auto elapsed = chrono::duration_cast<chrono::nanoseconds>(endTime - startTime).count();
    measure(elapsed);
}

bool Bench::measure(long long elapsed) {

    bool isToMeasure = ++measurementCount > warmupCount;

    if (isToMeasure) {
        sum += elapsed;
        if (elapsed < minTime) minTime = elapsed;
        if (elapsed > maxTime) maxTime = elapsed;

        // Increment the frequency of this elapsed time
        auto it = results->find(elapsed);
        if (it == results->end()) {
            results->insert({elapsed, 1});
        } else {
            it->second++;
        }
        size++;
    }
    
    return isToMeasure;
}

int Bench::getIterations() const {
    return measurementCount;
}

int Bench::getMeasurements() const {
    return size;
}

void Bench::reset() {
    reset(false);
}

void Bench::reset(bool repeatWarmup) {
    measurementCount = 0;
    sum = 0;
    if (!repeatWarmup) warmupCount = 0;
    minTime = numeric_limits<long long>::max();
    maxTime = numeric_limits<long long>::min();
    results->clear();
    size = 0;
}

bool Bench::isWarmingUp() const {
    return warmupCount <= measurementCount;
}

double Bench::avg() const {
    const int effectiveCount = measurementCount - warmupCount;
    if (effectiveCount <= 0) {
        return 0;
    }
    const double avg = static_cast<double>(sum) / effectiveCount;
    const double rounded = round(avg * 100.0) / 100.0;
    return rounded;
}

double Bench::getAverage() const {
    return avg();
}    

void Bench::printResults() const {
    printResults(true);
}

void Bench::printResults(bool includePercentiles) const {

    int effectiveCount = measurementCount - warmupCount;

    string effCountStr = formatWithCommas(effectiveCount);
    string warmupStr = formatWithCommas(warmupCount);
    string totalStr = formatWithCommas(measurementCount);

    cout << "Measurements: " << effCountStr
         << " | Warm-Up: " << warmupStr
         << " | Iterations: " << totalStr << endl;
         
    if (effectiveCount > 0) {

        auto [avgVal, avgUnit] = formatTime(avg());
        auto [minVal, minUnit] = formatTime(static_cast<double>(minTime));
        auto [maxVal, maxUnit] = formatTime(static_cast<double>(maxTime));
    
        cout << fixed << setprecision(3);
        cout << "Avg Time: " << avgVal << " " << avgUnit << " | "
             << "Min Time: " << minVal << " " << minUnit << " | "
             << "Max Time: " << maxVal << " " << maxUnit << endl;
    
        if (includePercentiles) printPercentiles();
    }
    
    cout << endl;
}

string Bench::formatWithCommas(long long value) {
    string numStr = to_string(value);
    int insertPosition = static_cast<int>(numStr.length()) - 3;
    while (insertPosition > 0) {
        numStr.insert(insertPosition, ",");
        insertPosition -= 3;
    }
    return numStr;
}

pair<double, string> Bench::formatTime(double nanos) {
    if (nanos >= 1'000'000'000.0) {
        double seconds = nanos / 1'000'000'000.0;
        return {roundToDecimals(seconds, 3), seconds > 1 ? "seconds" : "second"};
    } else if (nanos >= 1'000'000.0) {
        double millis = nanos / 1'000'000.0;
        return {roundToDecimals(millis, 3), millis > 1 ? "millis" : "milli"};
    } else if (nanos >= 1000.0) {
        double micros = nanos / 1000.0;
        return {roundToDecimals(micros, 3), micros > 1 ? "micros" : "micro"};
    } else {
        double ns = nanos;
        return {roundToDecimals(ns, 3), ns > 1 ? "nanos" : "nano"};
    }
}

double Bench::roundToDecimals(double d, int decimals) {
    double pow10 = pow(10.0, decimals);
    return round(d * pow10) / pow10;
}

void Bench::printPercentiles() const {

    if (size == 0) return;

    double percentiles[] = {0.75, 0.90, 0.99, 0.999, 0.9999, 0.99999};

    for (double p : percentiles) {
        addPercentile(p);
    }
}

string Bench::formatPercentage(double perc) {
    double p = perc * 100.0;

    ostringstream oss;
    oss << fixed << setprecision(6) << p;

    string s = oss.str();
    // remove trailing zeros
    while (s.back() == '0') {
        s.pop_back();
    }

    // if the last character is now a '.', remove it
    if (s.back() == '.') {
        s.pop_back();
    }

    // Append the '%' sign
    s += "%";

    return s;
}

void Bench::addPercentile(double perc) const {

    if (results->empty()) return;

    long long target = static_cast<long long>(llround(perc * size));
    if (target == 0) return;
    if (target > size) target = size;

    // Iterate through the map to find the top element at position target
    long long iTop = 0;
    long long sumTop = 0;
    long long maxTop = -1;

    for (auto &entry : *results) {
        long long time = entry.first;
        long long count = entry.second;

        for (int i = 0; i < count; i++) {
            iTop++;
            sumTop += time;
            if (iTop == target) {
                maxTop = time;
                goto FOUND;
            }
        }
    }

FOUND:;

    double avgTop = static_cast<double>(sumTop) / iTop;
    auto [avgVal, avgUnit] = formatTime(avgTop);
    auto [maxVal, maxUnit] = formatTime(static_cast<double>(maxTop));

    cout << fixed << setprecision(3);
    cout << formatPercentage(perc) << " = [avg: " << avgVal << " " << avgUnit
         << ", max: " << maxVal << " " << maxUnit << "]\n";
}

深入性能分析

代码设计特点

  1. 指针使用

    • C++版本大量使用指针以模拟Java的语义
    • 存储的"值"实际上都是指向同一个虚拟对象的指针
    • put方法通过const引用接收对象（在汇编层面是指针）
    • get方法返回非const指针

  2. 哈希表实现

    • 使用数组加链表的结构
    • 负载因子为100，这使得测试实际上更像是链表性能测试
    • 每个操作的时间足够长，可以通过Linux的clock_gettime进行测量

  3. 内存管理

    • 使用无限大小的空闲列表
    • 只在析构函数中进行删除操作
    • remove()操作将节点从桶的链表移动到空闲列表的头部
    • put操作优先使用空闲列表的头部节点，只在空闲列表为空时调用new

性能差异分析

  1. 内存分配模式

    • Java的GC和内存分配可能比C++的new操作更高效
    • 第二轮put操作仍然较慢，表明问题不仅仅在于内存分配

  2. 缓存影响

    • 链表遍历过程中的缓存未命中可能是主要瓶颈
    • Java的对象布局可能在某些情况下提供更好的缓存局部性

  3. 指针操作开销

    • Java使用32位压缩引用
    • C++使用原生指针（64位系统上为64位）
    • 即使使用32位编译，C++版本仍然较慢

  4. 编译器优化

    • JIT编译器可能对特定模式有更好的优化
    • 运行时优化可能比静态编译产生更好的代码

优化建议

  1. 自定义内存分配器

    • 实现针对Entry对象的特定分配器
    • 考虑使用内存池或区域分配策略
    • 优化内存布局以提高缓存效率

  2. 数据结构优化

    • 考虑使用开放寻址法代替链表
    • 优化负载因子以减少冲突
    • 实现更紧凑的内存布局

  3. 编译器选项

    • 探索更多的Clang优化标志
    • 考虑使用profile-guided optimization
    • 测试不同的内联策略

测试环境配置

系统环境

操作系统：Ubuntu 18.04.6 LTS
处理器：Intel(R) Xeon(R) E-2288G CPU @ 3.70GHz
架构：x86_64

编译器版本

clang++ 18.1.0
Java 23.0.1 (Oracle GraalVM)
native-image 23.0.1

编译参数说明

  • -Ofast: 启用最高级别的优化
  • -march=native: 针对本地CPU架构优化
  • -flto: 启用链接时优化
  • -std=c++17: 使用C++17标准
lxyzcm
关注
jit即使编译语言调用c++
daoer_sofu的专栏
09-24 363
python ctypes调用dll、so到处函数 import ctypes ll = ctypes.cdll.LoadLibrary lib = ll("./libpycall.so") lib.foo(1, 3) python的c++扩展，三种基本函数形式 static PyObject *MyFunction( PyObject *self, PyObject *args ); static PyObject *MyFunctionWithKeywords(PyObje
C++解释器、模板解释器和JIT的一些认识
qq_41775852的博客
11-24 1490
解释执行：包括C++解释器和模板解释器。解释执行并不是每次执行字节码时动态把它编译成机器码，而是将根据字节码的类型，转到对应的机器码去执行，即一个派发（switch）的过程。而C++解释器派发到的是由字节码对应的C++代码所编译成的机器码，模板解释器派发到的是字节码对应的汇编模板所生成的机器码。由于C++代码由编译器编译成机器码，比较冗余，所以执行速度慢，而模板解释器的汇编模板是直接由汇编代码专门编写的，执行效率高。所以解释执行执行速度较慢，并不是每次将字节码动态编码生成机器码的原因，这是错误的。而是对..
【C++】即时编译jit和xbyak的基本使用介绍
.
10-12 1217
一般来说，解释型编程语言都是依靠自身运行的虚拟机，在解释程序。有时候语言为了提高运行速度，不会去直接解释程序文本，而是模拟cpu执行方式，将文本代码执行一次翻译，翻译为类似cpu执行的汇编语言去执行。有些语言会模拟出几个CPU的寄存器，有些则使用栈的方式模拟寄存器。无论采用什么方式，基本都是循环读取文件的内容，按照一定规则去解释。这也就导致了，运行速度会慢一点，因为cpu最终执行的是虚拟机，而不是编写的语言。
编译C++程序（经验版）
IT菜鸟
10-05 1662
**链接**其实就是把其他**第三方库**和**自己源代码**生成的二进制目标文件融合在一起的过程。经过链接之后，那些第三方库中定义的函数就能被调用执行了。早期的一些操作系统一般使用**静态链接**的方式，现在基本上都在使用**动态链接**的方式。
在C++中使用LLVM的JIT功能进行代码优化：Optimization passes--PassManagerBuilder
个人博客
06-20 3702
今天找了一天的在LLVM中如何进行代码优化的方法。
探索C++的未来：Easy::jit，实时编译器库
gitblog_00005的博客
05-21 437
探索C++的未来：Easy::jit，实时编译器库 去发现同类优质开源项目:https://gitcode.com/ 项目简介 欢迎来到Easy::jit的世界！这是一个革命性的C++库，它利用了实时（Just-In-Time，JIT）代码生成的力量，为你的程序带来前所未有的性能提升。这个项目不仅允许你在运行时优化关键函数，还简化了与LLVM框架的交互，让你的开发过程更高效、更简单。 项目技术分析...
C++实现的简单哈希表为什么比Java慢：代码或基准测试问题？
电脑管家
12-26 391
为了尽量减少Java的GC与非GC C++之间的性能差异，我们使用无限制大小的空闲列表，只在析构函数中删除：如果remove()找到匹配项，它会将节点从存储桶的链接列表移动到空闲列表的头部。我们的基准测试比较了Java中简单小型哈希表（map）的实现与C++中逐行等效的实现。Bench类还将每次添加到C++中的一个std::map或Java中采用类似设计的自定义哈希map（负载因子远低于1）中，这在计时区域外，但第一次运行需要进行一些分配，因此在为正在进行基准测试的哈希表分配节点之间会发生这种情况。
C# AOT技术测试
最新发布
让每一个想学习编程的人，都能学会，都能看懂，看了都有收获！
02-22 1012
AOT（Ahead-of-Time） 是一种编程和编译技术，其核心思想是在程序执行前将源代码或中间代码完全编译成目标机器码（如二进制文件），而非像 JIT（Just-in-Time）那样在运行时动态编译.
《深入理解JAVA虚拟机》第十、十一章 编译运行期优化
乌鸦大大
02-23 714
《深入理解java虚拟机 笔记》第十章 (编译期)优化javac编译器编译过程java语法糖泛型与类型擦除自动装箱、拆箱与遍历循环条件编译 第十章 (编译期)优化 常说的编译其实是一段“不确定”的操作过程，可能是指一个前端编译器把.java文件转变成.class文件，也可能是指虚拟机后端运行期编译器（JIT编译器）把字节码变成机器码的过程，还可能是指静态提前编译器（AOT编译器）直接把.java文...
聊一聊java一些核心知识点
禅与计算机程序设计的艺术
10-20 1174
Java简单易学，相较于C语言和C++，没有指针的概念，所以操作和使用是会相对容易一些。平台无关性，即Java程序可以通过Java虚拟机在不同硬件不同操作系统上运行，而无需进行任何修改。面向对象:面向对象是一种程序设计技术，以木匠工作为例，使用面向对象方式实现的木匠的工作关注重点永远是制作椅子，其次才是工具。而面向过程则优先关注制作工具。与C++不同的是，Java不支持多继承，取而代之的是更加简单的接口的概念。编译与解释并存:与C++RustGo不同的是，java。
从Java8到Java21各版本新特性详解
小筱在线博客
01-04 3061
上面这张图是 Oracle 官方给出的 Oracle JDK 支持的时间线，可以看出，JDK 17的支持时间最长，可以延续到2029年9月。考虑到技术更新的速度，这次免费商用8年的时间可谓是经过精心考虑，旨在让用户放心地升级到JDK 17（不过JDK 8的支持时间更长，可以延续到2030年12月）。从JDK诞生到现在，仅有几个版本得到了长期支持，主要包括JDK 7、JDK 8、JDK 11以及即将发布的JDK 17，它将是继Java 8之后最重要的LTS版本，是Java社区八年努力的成果。
jitcc:用于C / C ++程序的即时编译工具-开源
04-13
jitcc是用于C / C ++程序的即时编译工具。
c++编译器里的字体_JIT 即时编译器
weixin_39894473的博客
10-28 459
一、概述即时编译器(Just In Time Compiler)，也称为 JIT 编译器，它的主要工作是把热点代码编译成与本地平台相关的机器码，并进行各种层次的优化，从而提高代码执行的效率。那么什么是热点代码呢？我们知道虚拟机通过解释器(Interpreter)来执行字节码文件，当虚拟机发现某个方法或代码块的运行特别频繁时，就会把这些代码认定为“热点代码”(Hot Spot Code)。即时编译器...
C++轻量级微服务_红帽工程师开发可用于物联网设备的轻量级JIT编译器MIR
weixin_39955421的博客
11-17 334
红帽的软件开发工程师Vladimir Makarov在开发者博客提到，他现在正开发一个轻量级JIT编译器(MIR，Medium Internal Representation)，编译速度与启动速度将比GCC或LLVM快100倍，作为现有MJIT编译器的补充，或是在现有JIT编译器无法作用时，成为替代方案。Vladimir Makarov提到，过去社群花费了大量的时间，对GCC和LLVM进行优化，除...
聊一聊 JIT 即时编译
W_J_G_的博客
02-24 368
良心公众号关注不迷路JIT 编译器，全称 Just In Time Compiler，被称作即时编译器。01JIT 的应用背景只看定义，并不能很清楚地了解 JIT 编译器的真实面目。这一切...
为什么感觉 C和C++ 不火了？
专注单片机实战教学，分享单片机学习资料
06-15 534
为什么感觉&nbsp;C和C++不火了？你身边的所有电子设备内,都是C或者C++写的, 会淘汰吗，有本事你们别用电子设备，C语言和C++在互联网领域热度肯定不如Java、python、js，我现在做的是工业软件，在工业软件、机器人、自动驾驶、嵌入式等等工业自动化相关领域，C/C++仍然是绝对的霸主地位。我这里有一套单片机物联网资料大全，想自学的小伙伴把，我想白嫖已经三连打在评论区，我给你发哦。选择什么编程语言不是根据难易程度，而是生态，比如做工业软件开发也可以选择Java，毕竟Java可以非常简单的
即时编译器 (JIT) 详解
weixin_33769207的博客
11-25 923
最近听我的导师他们讨论Java的即时编译器（JIT），当时并不知道这是啥东西，所以就借着周末的时间，学习了一下！ 一、概述 　　在部分的商用虚拟机（Sun HotSpot）中，Java程序最初是通过解释器（Interpreter）进行解释执行的，当虚拟机发现某个方法或代码块运行的特别频繁时，就会把这些代码认定为“热点代码”（Hot Spot Code）。为了提高热点代码的执行效率，在运行时，虚...
unity中的AOT、JIT、IL2CPP、Mono
热门推荐
cgExplorer的博客
06-29 1万+
一、JIT、AOT是什么 JIT，即Just-in-time,动态(即时)编译，边运行边编译；AOT，Ahead Of Time，指运行前编译，是两种程序的编译方式 二、优劣 JIT优点： ①可以根据当前硬件情况实时编译生成最优机器指令（ps. AOT也可以做到，在用户使用是使用字节码根据机器情况在做一次编译） ②可以根据当前程序的运行情况生成最优的机器指令序列 ③当程序需要支持动态链接时，只能使用JIT ④可以根据进程中内存的实际情况调整代码，使内存能够更充分的利用 JIT缺点： ①编译需要占用运行时资源
【程序语言】C/C++中如何使用Lua脚本
精灵的博客
08-09 5453
Lua作为一门优雅高效的脚本语言，开始受到越来越多的关注。很多对Lua感兴趣的朋友最郁闷的问题就是如何开始入手。那么现在我就也以一个初学者的身份，带大家一步一步开始Lua之旅： 1.确保有一个可用的编程环境，我这里示范的是VS2010，相信VS2008和VS2005是同理的。 2.到官网下载最新的Lua版本，这里给出的是LuaJIT的官网，JIT版本更加高效而且操作一模一样，所以直接上JIT了
Flutter入门：Dart语言基础与框架发展历程
6. 性能优化：Dart的即时编译（JIT）和提前编译（AOT）策略使其在运行时性能和启动速度上都有优秀表现。 7. 库支持：Dart拥有丰富的标准库和第三方库，如http、json_serializable等，方便开发者进行各种常见任务。 ...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值