开发者工具

This section provides a detailed description of some commonly used utilities for Taichi developers.

日志

Taichi uses spdlog as its logging system. Logs can have different levels, from low to high, they are:

  1. trace
  2. debug
  3. info
  4. warn
  5. error

The higher the level is, the more critical the message is.

The default logging level is info. You may override the default logging level by:

  1. Setting the environment variable like export TI_LOG_LEVEL=warn.
  2. Setting the log level from Python side: ti.set_logging_level(ti.WARN).

In Python, you may write logs using the ti.* interface:

  1. # Python
  2. ti.trace("Hello world!")
  3. ti.debug("Hello world!")
  4. ti.info("Hello world!")
  5. ti.warn("Hello world!")
  6. ti.error("Hello world!")

In C++, you may write logs using the TI_* interface:

  1. // C++
  2. TI_TRACE("Hello world!");
  3. TI_DEBUG("Hello world!");
  4. TI_INFO("Hello world!");
  5. TI_WARN("Hello world!");
  6. TI_ERROR("Hello world!");

If one raises a message of the level error, Taichi will be terminated immediately and result in a RuntimeError on Python side.

  1. int func(void *p) {
  2.   if (p == nullptr)
  3.     TI_ERROR("The pointer cannot be null!");
  5.   // will not reach here if p == nullptr
  6.   do_something(p);
  7. }

注解

For people from Linux kernels, TI_ERROR is just panic.

You may also simplify the above code by using TI_ASSERT:

  1. int func(void *p) {
  2.   TI_ASSERT_INFO(p != nullptr, "The pointer cannot be null!");
  3.   // or
  4.   // TI_ASSERT(p != nullptr);
  6.   // will not reach here if p == nullptr
  7.   do_something(p);
  8. }

基准测试和回归测试

  • 运行 ti benchmark 以基准模式运行测试。 这将记录 ti test 的性能，并将其保存在 benchmarks/output 中。
  • Run ti regression to show the difference between the previous result in benchmarks/baseline. And you can see if the performance is increasing or decreasing after your commits. This is really helpful when your work is related to IR optimizations.
  • Run ti baseline to save the benchmark result to benchmarks/baseline for future comparison, this may be executed on performance-related PRs, before they are merged into master.

例如，这是启用常数折叠优化传递后 ti regression 输出的一部分：

  1. linalg__________________polar_decomp______________________________
  2. codegen_offloaded_tasks                       37 ->    39    +5.4%
  3. codegen_statements                          3179 ->  3162    -0.5%
  4. codegen_kernel_statements                   2819 ->  2788    -1.1%
  5. codegen_evaluator_statements                   0 ->    14    +inf%
  7. linalg__________________init_matrix_from_vectors__________________
  8. codegen_offloaded_tasks                       37 ->    39    +5.4%
  9. codegen_statements                          3180 ->  3163    -0.5%
  10. codegen_kernel_statements                   2820 ->  2789    -1.1%
  11. codegen_evaluator_statements                   0 ->    14    +inf%

注解

Currently ti benchmark only supports benchmarking number-of-statements, no time benchmarking is included since it depends on hardware performance and therefore hard to compare if the baseline is from another machine. We are to purchase a fixed-performance machine as a time benchmark server at some point. Discussion at: https://github.com/taichi-dev/taichi/issue/948

The suggested workflow for the performance-related PR author to run the regression tests is:

  • Run ti benchmark && ti baseline in master to save the current performance as a baseline.
  • 运行 git checkout -b your-branch-name （分支名称）.
  • 尝试解决问题（第一阶段）。
  • 运行 ti benchmark && ti regression 获取结果。
  • （结果不理想）继续优化直至结果理想。
  • (If result OK) Run ti baseline to save stage 1 performance as a baseline.
  • 继续进行第二，第三阶段，同时以上的工作流程也同样适用。

程序崩溃时触发GDB（仅限于Linux操作系统）

  1. # Python
  2. ti.set_gdb_trigger(True)
  4. // C++
  5. CoreState::set_trigger_gdb_when_crash(true);
  7. # Shell
  8. export TI_GDB_TRIGGER=1

注解

使用 gdb 快速定位段错误 (segmentation fault) 和断言错误 (assertion failure): 在Taichi 崩溃时，gdb 会被触发并附着到当前的线程上。您可能需要输入和 sudo 超级用户权限相关的密码来允许 gdb 附着到当前的线程上。再输入 gdb 之后， 您可以使用 bt （backtrace）指令检查堆的回溯，从而定位产生错误的代码的具体行数。

Code coverage

To ensure that our tests covered every situation, we need to have coverage report. That is, to detect how many percents of code lines in is executed in test.

  • Generally, the higher the coverage percentage is, the stronger our tests are.
  • When making a PR, we want to ensure that it comes with corresponding tests. Or code coverage will decrease.
  • Code coverage statuses are visible at Codecov.
  • Currently, Taichi is only set up for Python code coverage report, not for C++ yet.
  1. ti test -C       # run tests and save results to .coverage
  2. coverage report  # generate a coverage report on terminal output
  3. coverage html    # generate a HTML form report in htmlcov/index.html

接口系统（遗留）

打印所有接口和单位

  1. ti.core.print_all_units()

序列化（遗留）

Taichi的序列化模块可以允许你将对象序列化/反序列化成二进制字符串。

You can use TI_IO macros to explicitly define fields necessary in Taichi.

  1. // TI_IO_DEF
  2. struct Particle {
  3.     Vector3f position, velocity;
  4.     real mass;
  5.     string name;
  7.     TI_IO_DEF(position, velocity, mass, name);
  8. }
  10. // TI_IO_DECL
  11. struct Particle {
  12.     Vector3f position, velocity;
  13.     real mass;
  14.     bool has_name
  15.     string name;
  17.     TI_IO_DECL() {
  18.         TI_IO(position);
  19.         TI_IO(velocity);
  20.         TI_IO(mass);
  21.         TI_IO(has_name);
  22.         // More flexibility:
  23.         if (has_name) {
  24.             TI_IO(name);
  25.         }
  26.     }
  27. }
  29. // TI_IO_DEF_VIRT();

进展通知（遗留）

当任务完成或崩溃时，taichi消息传递程序可以将邮件发送到 $TI_MONITOR_EMAIL 。 要启用的话：

  1. from taichi.tools import messenger
  2. messenger.enable(task_id='test')