华为手机好像有个同声直译的功能，就是比如发布会上如果说的是英文，可以直接在屏幕上输出中文字幕，那有没有方言的翻译的应用啊？之前看过几个视频，是江浙一带的老中医的讲座，讲的是方言，一句话听不懂！所以要有这样的应用就好了！

通过语音识别技术,在会议界面上实时呈现发言内容字幕,并实时翻译成英文。这对涉及跨国、跨语言开会场景非常有用。同时,可以区分发言人自动生成会议纪要,纪要可以导出后进行整理,无需手工记录,参会者可以轻松地聚焦会议讨论,同时也能获得完整的讨论记录。

NLP是什么?交叉学科: Computer Science,Artificial Intelligence and Computational Linguistics目标:解决计算机和人类（(自然）语言的交互问题，尤其是自动处理大规模自然语言语料难点:语言本身复杂、语境相关、抽象概念联想、软硬件技术限制，等等.NLP解决的5个基本问题(摘自李航老师的总结)分类: assigning a label to a string匹配:matching two strings翻译:transforming one string to another·结构化预测:mapping string to structure马氏决策过程:deciding next state given previous state and action自然语言处理（简称NLP），是研究计算机处理人类语言的一门技术，包括：1.句法语义分析：对于给定的句子，进行分词、词性标记、命名实体识别和链接、句法分析、语义角色识别和多义词消歧。2.信息抽取：从给定文本中抽取重要的信息，比如，时间、地点、人物、事件、原因、结果、数字、日期、货币、专有名词等等。通俗说来，就是要了解谁在什么时候、什么原因、对谁、做了什么事、有什么结果。涉及到实体识别、时间抽取、因果关系抽取等关键技术。3.文本挖掘（或者文本数据挖掘）：包括文本聚类、分类、信息抽取、摘要、情感分析以及对挖掘的信息和知识的可视化、交互式的表达界面。目前主流的技术都是基于统计机器学习的。4.机器翻译：把输入的源语言文本通过自动翻译获得另外一种语言的文本。根据输入媒介不同，可以细分为文本翻译、语音翻译、手语翻译、图形翻译等。机器翻译从最早的基于规则的方法到二十年前的基于统计的方法，再到今天的基于神经网络（编码-解码）的方法，逐渐形成了一套比较严谨的方法体系。5.信息检索：对大规模的文档进行索引。可简单对文档中的词汇，赋之以不同的权重来建立索引，也可利用1、2、3的技术来建立更加深层的索引。在查询的时候，对输入的查询表达式比如一个检索词或者一个句子进行分析，然后在索引里面查找匹配的候选文档，再根据一个排序机制把候选文档排序，最后输出排序得分最高的文档。6.问答系统： 对一个自然语言表达的问题，由问答系统给出一个精准的答案。需要对自然语言查询语句进行某种程度的语义分析，包括实体链接、关系识别，形成逻辑表达式，然后到知识库中查找可能的候选答案并通过一个排序机制找出最佳的答案。7.对话系统：系统通过一系列的对话，跟用户进行聊天、回答、完成某一项任务。涉及到用户意图理解、通用聊天引擎、问答引擎、对话管理等技术。此外，为了体现上下文相关，要具备多轮对话能力。同时，为了体现个性化，要开发用户画像以及基于用户画像的个性化回复。摘自  国际计算语言学协会（ACL）候任主席、NLP 领域资深研究者、MSRA副院长周明

 摘要：从开发环境、语法、属性、内存管理和Unicode等五部分，为你带来一份详细的Rust语言学习的精华总结内容。一、Rust开发环境指南1.1 Rust代码执行根据编译原理知识，编译器不是直接将源语言翻译为目标语言，而是翻译为一种“中间语言”，编译器从业人员称之为“IR”--指令集，之后再由中间语言，利用后端程序和设备翻译为目标平台的汇编语言。Rust代码执行：1) Rust代码经过分词和解析，生成AST（抽象语法树）。2) 然后把AST进一步简化处理为HIR（High-level IR），目的是让编译器更方便的做类型检查。3) HIR会进一步被编译为MIR（Middle IR），这是一种中间表示，主要目的是：a) 缩短编译时间；b) 缩短执行时间；c) 更精确的类型检查。4) 最终MIR会被翻译为LLVM IR，然后被LLVM的处理编译为能在各个平台上运行的目标机器码。Ø IR：中间语言Ø HIR：高级中间语言Ø MIR：中级中间语言Ø LLVM ：Low Level Virtual Machine，底层虚拟机。LLVM是构架编译器(compiler)的框架系统，以C++编写而成，用于优化以任意程序语言编写的程序的编译时间(compile-time)、链接时间(link-time)、运行时间(run-time)以及空闲时间(idle-time)无疑，不同编译器的中间语言IR是不一样的，而IR可以说是集中体现了这款编译器的特征：他的算法，优化方式，汇编流程等等，想要完全掌握某种编译器的工作和运行原理，分析和学习这款编译器的中间语言无疑是重要手段。由于中间语言相当于一款编译器前端和后端的“桥梁”，如果我们想进行基于LLVM的后端移植，无疑需要开发出对应目标平台的编译器后端，想要顺利完成这一工作，透彻了解LLVM的中间语言无疑是非常必要的工作。LLVM相对于gcc的一大改进就是大大提高了中间语言的生成效率和可读性， LLVM的中间语言是一种介于c语言和汇编语言的格式，他既有高级语言的可读性，又能比较全面地反映计算机底层数据的运算和传输的情况，精炼而又高效。1.1.1 MIRMIR是基于控制流图（Control Flow Graph，CFG）的抽象数据结构，它用有向图（DAG）形式包含了程序执行过程中所有可能的流程。所以将基于MIR的借用检查称为非词法作用域的生命周期。MIR由一下关键部分组成：l 基本块（Basic block，bb），他是控制流图的基本单位，Ø 语句（statement）Ø 终止句（Terminator）l 本地变量，占中内存的位置，比如函数参数、局部变量等。l 位置（Place），在内存中标识未知的额表达式。l 右值（RValue），产生值的表达式。具体的工作原理见《Rust编程之道》的第158和159页。可以在http://play.runst-lang.org中生成MIR代码。1.1 Rust安装Ø 方法一：见Rust官方的installation章节介绍。实际上就是调用该命令来安装即可：curl https://sh.rustup.rs -sSf | shØ 方法二：下载离线的安装包来安装，具体的可见Rust官方的Other Rust Installation Methods章节。1.2 Rust编译&运行1.2.1 Cargo包管理Cargo是Rust中的包管理工具，第三方包叫做crate。Cargo一共做了四件事：l 使用两个元数据（metadata）文件来记录各种项目信息l 获取并构建项目的依赖关系l 使用正确的参数调用rustc或其他构建工具来构建项目l 为Rust生态系统开发建议了统一标准的工作流Cargo文件：l Cargo.lock：只记录依赖包的详细信息，不需要开发者维护，而是由Cargo自动维护l Cargo.toml：描述项目所需要的各种信息，包括第三方包的依赖cargo编译默认为Debug模式，在该模式下编译器不会对代码进行任何优化。也可以使用--release参数来使用发布模式。release模式，编译器会对代码进行优化，使得编译时间变慢，但是代码运行速度会变快。官方编译器rustc，负责将rust源码编译为可执行的文件或其他文件（.a、.so、.lib等）。例如：rustc box.rsRust还提供了包管理器Cargo来管理整个工作流程。例如：lcargo newfirst_pro_create ：创建名为first_pro_create的项目lcargo new --libfirst_lib_create ：创建命令first_lib_create的库项目lcargo doclcargo doc --openlcargo testlcargo test -- --test-threads=1lcargo buildlcargo build --releaselcargo runlcargo install --pathlcargo uninstallfirst_pro_createlcargo new –bin use_regex1.2.2 使用第三方包Rust可以在Cargo.toml中的[dependencies]下添加想依赖的包来使用第三方包。然后在src/main.rs或src/lib.rs文件中，使用extern crate命令声明引入该包即可使用。例如：值得注意的是，使用extern crate声明包的名称是linked_list，用的是下划线“_”，而在Cargo.toml中用的是连字符“-”。其实Cargo默认会把连字符转换成下划线。Rust也不建议以“-rs”或“_rs”为后缀来命名包名，而且会强制性的将此后缀去掉。具体的见《Rust编程之道》的第323页。1.4 Rust常用命令1.5 Rust命令规范Ø 函数： 蛇形命名法（snake_case），例如：func_name()Ø 文件名： 蛇形命名法（snake_case），例如file_name.rs、main.rsØ 临时变量名：蛇形命名法（snake_case）Ø 全局变量名：Ø 结构体： 大驼峰命名法，例如：struct FirstName { name: String}Ø enum类型: 大驼峰命名法。Ø 关联常量：常量名必须全部大写。什么是关联常量见《Rust编程之道》的第221页。Ø Cargo默认会把连字符“-”转换成下划线“_”。Ø Rust也不建议以“-rs”或“_rs”为后缀来命名包名，而且会强制性的将此后缀去掉。二、Rust语法2.1 疑问&总结2.1.1 Copy语义 && Move语义（Move语义必须转移所有权）类型越来越丰富，值类型和引用类型难以描述全部情况，所以引入了：Ø 值语义（Value Semantic）复制以后，两个数据对象拥有的存储空间是独立的，互不影响。基本的原生类型都是值语义，这些类型也被称为POD（Plain old data）。POD类型都是值语义，但是值语义类型并不一定都是POD类型。具有值语义的原生类型，在其作为右值进行赋值操作时，编译器会对其进行按位复制。Ø 引用语义（Reference Semantic）复制以后，两个数据对象互为别名。操作其中任意一个数据对象，则会影响另外一个。智能指针Box<T>封装了原生指针，是典型的引用类型。Box<T>无法实现Copy，意味着它被rust标记为了引用语义，禁止按位复制。引用语义类型不能实现Copy，但可以实现Clone的clone方法，以实现深复制。在Rust中，可以通过是否实现Copy trait来区分数据类型的值语义和引用语义。但为了更加精准，Rust也引用了新的语义：复制（Copy）语义和移动（Move）语义。Ø Copy语义：对应值语义，即实现了Copy的类型在进行按位复制时是安全的。Ø Move语义：对应引用语义。在Rust中不允许按位复制，只允许移动所有权。2.1.2 哪些实现了CopyØ 结构体 ：当成员都是复制语义类型时，不会自动实现Copy。Ø 枚举体 ：当成员都是复制语义类型时，不会自动实现Copy。结构体 && 枚举体：1) 所有成员都是复制语义类型时，需要添加属性#[derive(Debug,Copy,Clone)]来实现Copy。2) 如果有移动语义类型的成员，则无法实现Copy。Ø 元组类型 ：本身实现了Copy。如果元素均为复制语义类型，则默认是按位复制，否则执行移动语义。Ø 字符串字面量 &str： 支持按位复制。例如：c = “hello”; 则c就是字符串字面量。2.1.3 哪些未实现CopyØ 字符串对象String ：to_string() 可以将字符串字面量转换为字符串对象。2.1.4 哪些实现了Copy traitØ 原生整数类型对于实现Copy的类型，其clone方法只需要简单的实现按位复制即可。2.1.5 哪些未实现Copy traitØ Box<T>实现了Copy trait，有什么作用？实现Copy trait的类型同时拥有复制语义，在进行赋值或者传入函数等操作时，默认会进行按位复制。Ø 对于默认可以安全的在栈上进行按位复制的类型，就只需要按位复制，也方便管理内存。Ø 对于默认只可在堆上存储的数据，必须进行深度复制。深度复制需要在堆内存中重新开辟空间，这会带来更多的性能开销。2.1.6 哪些是在栈上的？哪些是在堆上的？2.1.7 let绑定Ø Rust声明的绑定默认为不可变。Ø 如果需要修改，可以用mut来声明绑定是可变的。2.2 数据类型很多编程语言中的数据类型是分为两类：Ø 值类型一般是指可以将数据都保存在同一位置的类型。例如数值、布尔值、结构体等都是值类型。值类型有：l原生类型l结构体l枚举体Ø 引用类型会存在一个指向实际存储区的指针。比如通常一些引用类型会将数据存储在堆中，而栈中只存放指向堆中数据的地址（指针）。引用类型有：l普通引用类型l原生指针类型2.2.1 基本数据类型布尔类型bool类型只有两个值：true和false。基本数字类型主要关注取值范围，具体的见《Rust编程之道》的第26页。字符类型用单引号来定义字符（char）类型。字符类型代表一个Unicode标量值，每个字节占4个字节。数组类型数组的类型签名为[T; N]。T是一个泛型标记，代表数组中元素的某个具体类型。N代表数组长度，在编译时必须确定其值。数组特点：l 大小固定l 元素均为同类型l 默认不可变切片类型切片（Slice）类型是对一个数组的引用片段。在底层，切片代表一个指向数组起始位置的指针和数组长度。用[T]类型表示连续序列，那么切片类型就是&[T]和&mut[T]。具体的见《Rust编程之道》的第30页。str字符串类型字符串类型str，通常是以不可变借用的形式存在，即&str（字符串切片）。Rust将字符串分为两种：1) &str ：固定长度字符串2) String ：可以随意改变其长度。&str字符串类型由两部分组成：1) 指向字符串序列的指针；2) 记录长度的值。&str存储于栈上，str字符串序列存储于程序的静态只读数据段或者堆内存中。&str是一种胖指针。never类型never类型，即!。该类型用于表示永远不可能有返回值的计算类型。其他（此部分不属于基本数据类型）此部分不属于基本数据类型，由于编排问题，暂时先放在此处。胖指针胖指针：包含了动态大小类型地址信息和携带了长度信息的指针。具体的见《Rust编程之道》的第54页。零大小类型零大小类型（Zero sized Type，ZST）的特点是：它们的值就是其本身，运行时并不占用内存空间。单元类型和单元结构体大小为零，由单元类型组成的数组大小也是零。ZST类型代表的意义是“空”。底类型底类型其实是介绍过的never类型，用叹号（!）表示。它的特点是：l 没有值l 是其他任意类型的子类型如果说ZST类型表示“空”的话，那么底类型就表示“无”。底类型无值，而且它可以等价于任意类型。具体的见《Rust编程之道》的第57页。2.2.2 复合数据类型元组Rust提供了4中复合数据类型：l元组（Tuple）l结构体（Struct）l枚举体（Enum）l联合体（Union）先来介绍元组。元组是一种异构有限序列，形如(T,U,M,N)。所谓异构，就是指元组内的元素可以是不同类型。所谓有限，是指元组有固定的长度。l 空元组： ()l 只有一个值时，需要加逗号： (0,)结构体Rust提供了3中结构体：l具名结构体l元组结构体l单元结构体例如：Ø 具名结构体：struct People {name: &’static str,}Ø 元组结构体：字段没有名称，只有类型：struct Color(i32, i32, i32);当一个元组结构体只有一个字段的时候，称为New Type模式。例如：  struct Integer(u32);Ø 单元结构体：没有任何字段的结构体。单元结构体实例就是其本身。struct Empty;结构体更新语法使用Struct更新语法（..）从其他实例创建新实例。当新实例使用旧实例的大部分值时，可以使用struct update语法。 例如：#[derive(Debug,Copy,Clone)]struct Book<’a> {name: &’a str,isbn:  i32,version: i32,}let book = Book {name: “Rust编程之道”,  isbn: 20181212, version: 1};let book2 = Book {version: 2, ..book};注：l 如果结构体使用了移动语义的成员字段，则不允许实现Copy。l Rust不允许包含了String类型字段的结构体实现Copy。l 更新语法会转移字段的所有权。枚举体该类型包含了全部可能的情况，可以有效的防止用户提供无效值。例如：enum Number {Zero,One,}Rust还支持携带类型参数的枚举体。这样的枚举值本质上属于函数类型，他可以通过显式的指定类型来转换为函数指针类型。例如：enum IpAddr {          V4(u8, u8, u8, u8),V6(String),}枚举体在Rust中属于非常重要的类型之一。例如：Option枚举类型。联合体2.2.3 常用集合类型线性序列：向量在Rust标准库std::collections模块下有4中通用集合类型，分别如下：线性序列：向量（Vec）、双端队列（VecDeque）、链表（LinkedList）Key-Value映射表：无序哈希表（HashMap）、有序映射表（BTreeMap）集合类型：无序集合（HashSet）、有序集合（BTreeSet）优先队列：二叉堆（BinaryHeap）具体的见《Rust编程之道》的第38页和271页。向量也是一种数组，和基本数据类型中的数组的区别在于：向量可动态增长。示例：let mut v1 = vec![];let mut v2 = vec![0; 10];let mut v3 = Vec::new();vec!是一个宏，用来创建向量字面量。线性序列：双端队列双端队列（Double-ended Queue，缩写Deque）是一种同时具有队列（先进先出）和栈（后进先出）性质的数据结构。双端队列中的元素可以从两端弹出，插入和删除操作被限定在队列的两端进行。示例：use std::collections::VecDeque;let mut buf = VecDeque::new();buf.push_front(1);buf.get(0);buf.push_back(2);线性序列：链表Rust提供的链表是双向链表，允许在任意一端插入或弹出元素。最好使用Vec或VecDeque类型，他们比链表更加快速，内存访问效率更高。示例：use std::collections::LinkedList;let mut list = LinkedList::new();list.push_front(‘a’);list.append(&mut list2);list.push_back(‘b’);Key-Value映射表：HashMap和BTreeMapHashMap<K, V> => 无序BTreeMap<K, V> => 有序其中HashMap要求key是必须可哈希的类型，BTreeMap的key必须是可排序的。Value必须是在编译期已知大小的类型。示例：use std::collections::BTreeMap;use std::collections::HashMap;let mut hmap = HashMap::new();let mut bmap = BTreeMap::new();hmap.insert(1,”a”);bmap.insert(1,”a”);集合：HashSet和BTreeSetHashSet<K>和BTreeSet<K>其实就是HashMap<K, V>和BTreeMap<K, V>把Value设置为空元组的特定类型。l 集合中的元素应该是唯一的。l HashSet中的元素都是可哈希的类型，BTreeSet中的元素必须是可排序的。l HashSet应该是无序的，BTreeSet应该是有序的。示例：use std::collections::BTreeSet;use std::collections::HashSet;let mut hset = HashSet::new();let mut bset = BTreeSet::new();hset.insert(”This is a hset.”);bset.insert(”This is a bset”);优先队列：BinaryHeapRust提供的优先队列是基于二叉最大堆（Binary Heap）实现的。示例：use std::collections::BinaryHeap;let mut heap = BinaryHeap::new();heap.peek();                           => peek是取出堆中最大的元素heap.push(98);容量（Capacity）和大小（Size/Len）无论是Vec还是HashMap，使用这些集合容器类型，最重要的是理解容量（Capacity）和大小（Size/Len）。容量是指为集合容器分配的内存容量。大小是指集合中包含的元素数量。2.2.4 Rust字符串Rust字符串分为以下几种类型：l str：表示固定长度的字符串l String：表示可增长的字符串l CStr：表示由C分配而被Rust借用的字符串。这是为了兼容windows系统。l CString：表示由Rust分配且可以传递给C函数使用的C字符串，同样用于和C语言交互。l OsStr：表示和操作系统相关的字符串。这是为了兼容windows系统。l OsString：表示OsStr的可变版本。与Rust字符串可以相互交换。l Path：表示路径，定义于std::path模块中。Path包装了OsStr。l PathBuf：跟Path配对，是path的可变版本。PathBuf包装了OsString。str属于动态大小类型（DST），在编译期并不能确定其大小。所以在程序中最常见的是str的切片（Slice）类型&str。&str代表的是不可变的UTF-8字节序列，创建后无法再为其追加内容或更改其内容。&str类型的字符串可以存储在任意地方：Ø 静态存储区Ø 堆分配Ø 栈分配具体的见《Rust编程之道》的第249页。String类型本质是一个成员变量为Vec<u8>类型的结构体，所以它是直接将字符内容存放于堆中的。String类型由三部分组成：Ø 执行堆中字节序列的指针（as_ptr方法）Ø 记录堆中字节序列的字节长度（len方法）Ø 堆分配的容量（capacity方法）2.2.4.1 字符串处理方式Rust中的字符串不能使用索引访问其中的字符，可以通过bytes和chars两个方法来分别返回按字节和按字符迭代的迭代器。Rust提供了另外两种方法：get和get_mut来通过指定索引范围来获取字符串切片。具体的见《Rust编程之道》的第251页。2.2.4.2 字符串修改Ø 追加字符串：push和push_str，以及extend迭代器Ø 插入字符串：insert和insert_strØ 连接字符串：String实现了Add<&str>和AddAssign<&str>两个trait，所以可以使用“+”和“+=”来连接字符串Ø 更新字符串：通过迭代器或者某些unsafe的方法Ø 删除字符串：remove、pop、truncate、clear和drain具体的见《Rust编程之道》的第255页。2.2.4.3 字符串的查找Rust总共提供了20个方法涵盖了以下几种字符串匹配操作：Ø 存在性判断Ø 位置匹配Ø 分割字符串Ø 捕获匹配Ø 删除匹配Ø 替代匹配具体的见《Rust编程之道》的第256页。2.2.4.4 类型转换Ø parse：将字符串转换为指定的类型Ø format!宏：将其他类型转成成字符串2.2.5 格式化规则l 填充字符串宽度：{:5},5是指宽度为5l 截取字符串：{:.5}l 对齐字符串：{:>}、{:^}、{:<}，分别表示左对齐、位于中间和右对齐l{:*^5} 使用*替代默认空格来填充l 符号+：表示强制输出整数的正负符号l 符号#：用于显示进制的前缀。比如：十六进制0xl 数字0：用于把默认填充的空格替换成数字0l {:x} ：转换成16进制输出l {:b} ：转换成二进制输出l{:.5}：指定小数点后有效位是5l {:e}：科学计数法表示具体的见《Rust编程之道》的第265页。2.2.6 原生字符串声明语法：r”…”原生字符串声明语法（r”…”）可以保留原来字符串中的特殊符号。具体的见《Rust编程之道》的第270页。2.2.7 全局类型Rust支持两种全局类型：l 普通常量（Constant）l 静态变量（Static）区别：l 都是在编译期求值的，所以不能用于存储需要动态分配内存的类型l 普通常量可以被内联的，它没有确定的内存地址，不可变l 静态变量不能被内联，它有精确的内存地址，拥有静态生命周期l 静态变量可以通过内部包含UnsafeCell等容器实现内部可变性l 静态变量还有其他限制，具体的见《Rust编程之道》的第326页l 普通常量也不能引用静态变量在存储的数据比较大，需要引用地址或具有可变性的情况下使用静态变量。否则，应该优先使用普通常量。但也有一些情况是这两种全局类型无法满足的，比如想要使用全局的HashMap，在这种情况下，推荐使用lazy_static包。利用lazy_static包可以把定义全局静态变量延迟到运行时，而非编译时。

 摘要：性能优化指在不影响系统运行正确性的前提下，使之运行得更快，完成特定功能所需的时间更短，或拥有更强大的服务能力。#一、思维导图#二、什么是性能优化？性能优化指在不影响系统运行正确性的前提下，使之运行得更快，完成特定功能所需的时间更短，或拥有更强大的服务能力。##关注不同程序有不同的性能关注点，比如科学计算关注运算速度，游戏引擎注重渲染效率，而服务程序追求吞吐能力。服务器一般都是可水平扩展的分布式系统，系统处理能力取决于单机负载能力和水平扩展能力，所以，提升单机性能和提升水平扩展能力是两个主要方向，理论上系统水平方向可以无限扩展，但水平扩展后往往导致通信成本飙升（甚至瓶颈），同时面临单机处理能力下降的问题。##指标衡量单机性能有很多指标，比如：QPS（Query Per Second）、TPS、OPS、IOPS、最大连接数、并发数等评估吞吐的指标。CPU为了提高吞吐，会把指令执行分为多个阶段，会搞指令Pipeline，同样，软件系统为了提升处理能力，往往会引入批处理（攒包），跟CPU流水线会引起指令执行Latency增加一样，伴随着系统负载增加也会导致延迟（Latency）增加，可见，系统吞吐和延迟是两个冲突的目标。显然，过高的延迟是不能接受的，所以，服务器性能优化的目标往往变成：追求可容忍延迟（Latency）下的最大吞吐（Throughput）。延迟（也叫响应时间：RT）不是固定的，通常在一个范围内波动，我们可以用平均时延去评估系统性能，但有时候，平均时延是不够的，这很容易理解，比如80%的请求都在10毫秒以内得到响应，但20%的请求时延超过2秒，而这20%的高延迟可能会引发投诉，同样不可接受。一个改进措施是使用TP90、TP99之类的指标，它不是取平均，而是需确保排序后90%、99%请求满足时延的要求。通常，执行效率（CPU）是我们的重点关注，但有时候，我们也需要关注内存占用、网络带宽、磁盘IO等，影响性能的因素很多，它是一个复杂而有趣的问题。#三、基础知识能编写运行正确的程序不一定能做性能优化，性能优化有更高的要求，这样讲并不是想要吓阻想做性能优化的工程师，而是实事求是讲，性能优化既需要扎实的系统知识，又需要丰富的实践经验，只有这样，你才能具备case by case分析问题解决问题的能力。所以，相比直接给出结论，我更愿意多花些篇幅讲一些基础知识，我坚持认为底层基础是理解并掌握性能优化技能的前提，值得花费一些时间研究并掌握这些根技术。##CPU架构你需要了解CPU架构，理解运算单元、记忆单元、控制单元是如何既各司其职又相互配合完成工作的。你需要了解CPU如何读取数据，CPU如何执行任务。你需要了解数据总线，地址总线和控制总线的区别和作用。你需要了解指令周期：取指、译指、执行、写回。你需要了解CPU Pipeline，超标量流水线，乱序执行。你需要了解多CPU、多核心、逻辑核、超线程、多线程、协程这些概念。##存储金字塔CPU的速度和访存速度相差200倍，高速缓存是跨越这个鸿沟的桥梁，你需要理解存储金字塔，而这个层次结构思维基于着一个称为局部性原理（principle of locality）的思想，它对软硬件系统的设计和性能有着极大的影响。局部性又分为时间局部性和空间局部性。### 缓存现代计算机系统一般有L1-L2-L3三级缓存。比如在我的系统，我通过进入 /sys/devices/system/cpu/cpu0/cache/index0 1 2 3目录下查看。size对应大小、type对应类型、coherency_line_size对应cache line大小。每个CPU核心有独立的L1、L2高速缓存，所以L1和L2是on-chip缓存；L3是多个CPU核心共享的，它是off-chip缓存。L1缓存又分为i-cache（指令缓存）和d-cache（数据缓存），L1缓存通常只有32K/64KB，速度高达4 cycles。L2缓存能到256KB，速度在8 cycles左右。L3则高达30MB，速度32 cycles左右。而内存高达数G，访存时延则在200 cycles左右。所以CPU->寄存器->L1->L2->L3->内存->磁盘构成存储层级结构：越靠近CPU，存储容量越小、速度越快、单位成本越高，越远离CPU，存储容量越大、速度越慢、单位成本越低。### 虚拟存储器（VM）进程和虚拟地址空间是操作系统的2个核心抽象。系统中的所有进程共享CPU和主存资源，虚拟存储是对主存的抽象，它为每个进程提供一个大的、一致的、私有的地址空间，我们gdb调试的时候，打印出来的变量地址是虚拟地址。操作系统+CPU硬件（MMU）紧密合作完成虚拟地址到物理地址的翻译（映射），这个过程总是沉默的自动的进行，不需要应用程序员的任何干预。每个进程有一个单独的页表（Page Table），页表是一个页表条目（PTE）的数组，该表的内容由操作系统管理，虚拟地址空间中的每个页（4K或者8K）通过查找页表找到物理地址，页表往往是层级式的，多级页表减少了页表对存储的需求，命失（Page Fault）将导致页面调度（Swapping或者Paging），这个惩罚很重，所以，我们要改善程序的行为，让它有更好的局部性，如果一段时间内访存的地址过于发散，将导致颠簸（Thrashing），从而严重影响程序性能。为了加速地址翻译，MMU中增加了一个关于PTE的小的缓存，叫翻译后备缓冲器（TLB），地址翻译单元做地址翻译的时候，会先查询TLB，只有TLB命失才会查询高速缓存（L1-2-3）。## 汇编基础虽然写汇编的场景越来越少，但读懂汇编依然很有必要，理解高级语言的程序是怎么转化为汇编语言有助于我们编写高质量高性能的代码。对于汇编，至少需要了解几种寻址模式，了解数据操作、分支、传送、控制跳转指令。理解C语言的if else、while/do while/for、switch case、函数调用是怎么翻译成汇编代码。理解ebp+esp寄存器在函数调用过程中是如何构建和撤销栈帧的。理解函数参数和返回值是怎么传递的。## 异常和系统调用异常会导致控制流突变，异常控制流发生在计算机系统的各个层次，异常可以分为四类：中断（interrupt）：中断是异步发生的，来自处理器外部IO设备信号，中断处理程序分上下部。陷阱（trap）：陷阱是有意的异常，是执行一条指令的结果，系统调用是通过陷阱实现的，陷阱在用户程序和内核之间提供一个像过程调用一样的接口：系统调用。故障（fault）：故障由错误情况引起，它有可能被故障处理程序修复，故障发生，处理器将控制转移到故障处理程序，缺页（Page Fault）是经典的故障实例。终止（abort）：终止是不可恢复的致命错误导致的结果，通常是硬件错误，会终止程序的执行。系统调用：## 内核态和用户态你需要了解操作系统的一些概念，比如内核态和用户态，应用程序在用户态运行我们编写的逻辑，一旦调用系统调用，便会通过一个特定的陷阱陷入内核，通过系统调用号标识功能，不同于普通函数调用，陷入内核态和从内核态返回需要做上下文切换，需要做环境变量的保存和恢复工作，它会带来额外的消耗，我们编写的程序应避免频繁做context swap，提升用户态的CPU占比是性能优化的一个目标。

近日，Scrum敏捷方法框架的两位创始人Ken Schwaber和Jeff Sutherland通过直播，向大家宣告发布了Scrum指南的2020年版本。作为Scrum的创始人，Scrum指南被广泛认可为是Scrum框架的权威定义和解释，有着极高的地位，也因此备受争议。而两位创始人能够持续倾听社区实践者们的反馈，谨慎但持续地刷新Scrum指南，以响应Scrum在实践应用中所面临的问题以及实践者的困惑，这本身也是一种敏捷精神的体现。 那么，我们一起来看看这个2020年版本都有些什么变化。在scrumguides.org网站上有专门页面介绍各个版本之间的改变，英文过硬的朋友，也可以直接打开链接阅读：https://scrumguides.org/revisions.html。注意，下文中，我使用了“产品列表”、“Sprint列表”等词汇，但是在2020年版本的指南中并未翻译这两个及其他一些词汇，而保留了英文原文，如Product Backlog、Sprint Backlog。为了行文方便，我仍使用中文表达。 2020年版本相比2017年版本的变化，根据官方介绍，主要涉及七个方面的改变。接下来让我们逐个解读这些变化。变化标题那个段落是官方文档中的表述，下方缩进部分的文字是我的个人见解。 变化1 —— 减少预描述性：这些年来，Scrum指南逐渐变得有些过于详述。这份2020年版本旨在通过删除或软化预描述性语言的方式让Scrum回归为一个仅够（最小化但足以生效）的框架。比如，移除了每日Scrum的三个问题、软化了PBI（产品列表条目）属性的描述、软化了Sprint列表中关于回顾改进条目的描述、软化了Sprint取消章节的内容，等等； 确实有点回归初衷的感觉，从一开始，在众多敏捷方法论当中，Scrum就属于是最为简洁的那个，而且两位创始人在各种场合的讲解也都强调具体如何操作是灵活的。而移除的这些个内容，其实都是过去这些年来大家在实践中比较纠结的焦点。比如说每日Scrum到底要不要严格遵守三个问题的格式？公说公有理婆说婆有理，其实是针对不同成熟度的团队，坚持和不坚持各有利弊，但写在指南里面，难免被认为是普适性都要遵守的。 至于回顾改进条目，是因为在2017年版本里面有这么一段话：Sprint 产品待办列表将开发团队用来达成 Sprint 目标的所有工作变得清晰可见。为了确保持续改进，它至少包括一项在前次回顾会议中确定下来的高优先级的过程改进。删除这段话，对我来讲，没有什么影响，该改进的就应该落实，怎么落实最好，就是在当前Sprint列表里面以任务或故事形式来进行管理是最顺手的。但对于不那么熟悉Scrum的实践者来讲，估计又要争论Sprint回顾会议上制定的改进措施如何落实了。 至于Sprint取消，则是从原来大概20句话简化到了如今就一句话。删除的多是车轱辘话，这个改进应该没啥问题。但简化到就这么一句话这个做法，相当于进一步强化了PO对Sprint的生杀大权，或者说独裁权。三种角色的职责与权力划分是否还能够保持良好的平衡，有点难说，外国人喜欢强调分工和职责，但不太去讲如何基于不同分工角色合作的动力，关键是能动性往往却是合作能够产生效果的基础。 变化2 —— 一个团队聚焦一个产品：目标是要破除在团队内还有一个单独团队的概念，这种做法会导致在PO和开发团队之间出现“代理”或“我们和他们”等行为。现在，就只有一个Scrum团队聚焦于同一个目标，分别承担三组不同职责：PO、SM和开发者。 不熟悉的朋友可能未必能很好理解这个改变。在以前，Scrum指南在三种角色的名称定义上有那么点不够严谨，说是有PO、SM和开发团队三种角色，然后三种角色共同构成了一个Scrum团队，相当于是说Scrum团队 = PO + SM + 开发团队，大家就会很纠结那到底是几个团队呢。对于PO、SM可能都还好，但对于开发团队的成员来讲，他们就会很困惑，我到底属于哪个团队？说一名成员属于开发团队又属于Scrum团队，对于成员自身的身份认同和团队认同方面，是会造成非常大的困扰的。所以这次直接去掉开发团队里面的团队一词，就是对这种争议的直接回应。2017年简中版本把很多术语都翻译成了中文，虽然我个人意见是倾向于不翻译、保留原文的，而这次2020年简中版本中则多数都保留了英文原文，比如开发团队在2017年版本里面的原文是The Development Team，而在2020年版本里面改成Developers且保留了英文原文。但我还是比较关注这个Developers的翻译的，因为通常来讲Developers都会被等同于开发人员，大家潜意识里面去理解的技能模型就是会写代码的，这就对非编码人员或非编码技能不够友好，会影响到团队的团结氛围以及非编码人员或非编码技能的能力构建和职业发展的。2020年版本里面并没有对Developers的具体技能模型和更详细的分工或角色进行描述，从好的角度看，是因为强调自管理，所以把决策权留给了这个Scrum团队自己去决定。但从坏的角度看，就是不负责任了，因为这就意味着要能够应用好Scrum框架，做好团队角色的分工和合作，会依赖于主导者或SM或敏捷教练的经验水平，这也就难以保障Scrum落地的效果。 变化3 ——引入产品目标：2020年版本Scrum指南引入了产品目标的概念，以帮助Scrum团队聚焦于一个更有价值的目标。每个Sprint都应该带动产品更接近最终产品目标。 Scrum以前其实并没有太明显或者着重去强调自己是面向产品型研发这个场景的，虽然PO这个名字就已经表明了态度，毕竟它叫产品负责人嘛，当然是围绕产品转的。在引入了产品目标这个概念之后，进一步强化了框架本身对产品型研发场景或工作场景的聚焦。Scrum能否用于项目研发场景，在过去那么多年，是一直有争议的。将Scrum框架跟整个项目研发场景对应，会觉得不适合，因为Scrum框架定义中用产品列表去承载整体需求管理，而产品列表是开放、持续刷新的，而项目范围则通常都是锁定的。如果用Scrum里面的Sprint去对应项目型研发场景下的项目，从资源、时限、范围等角度看，都是一种提前锁定的模式，非常接近，但Sprint的时长周期，又跟一般所理解的项目周期相去甚远，就好像大家都是猫科，但你这个小猫咪的养育方法，用去养育大老虎总觉得有些不对劲。 所以，这个变化，就要看两位创始人给Scrum设定的愿景到底是啥了。一方面是否真的想要强化面向产品型研发的场景，另一方面，第7个变化说删除IT工作化表述，但其实Product这个词也有很强的IT工作化的暗示。但我想如果要完全去IT化，估计就是伤筋动骨，类似全身整容，比如Product这个词汇，贯穿了Scrum框架的整个脉络。要剔除它，谈何容易。 变化4 —— Sprint目标、完成定义和产品目标的归宿：以前版本的Scrum指南提到了Sprint目标和完成定义，但并没有真正给它们身份。它们并非工件，但却或多或少都跟工件有关系。2020年版本不仅是增加了产品目标，还进行了更清晰的阐述。三大工件如今都纳入了与之对应的“承诺”。产品列表的承诺就是产品目标；Sprint列表的承诺就是Sprint目标；增量的承诺就是完成定义（现在已经去掉了双引号）。它们的存在就是为了让各大工件的进展变得更清晰和更聚焦。 搞笑点说，就是以前它们都是地下恋情，名不正言不顺的。现在正式給它们证了个婚，Sprint列表跟Sprint目标结婚拉钩、增量跟完成定义结婚拉钩，然后给产品列表配了个对象叫产品目标，也结婚拉钩。其实是好事，但另一方面来讲，也说明Scrum框架在变得更加流程化、规范化，因为从流程定义的角度来讲，不可能只是定义过程中的动作，而不定义过程的结果或者说准出标准的。这几个承诺某种程度上就有点质量标准或者准出标准的味道。 当然，改变嘛，没有绝对好和绝对坏的。比如产品目标，2020年中文版本中搜索可以找到22个地方，只有一个地方说了谁来制定，那就是PO负责“开发并明确地沟通Product Goal”。这必然带来问题，相当于Product Goal的定义和决策权是独裁的、不受约束的，那么如果PO以产品目标的变化为由，提出可能不那么吻合Scrum精神的要求，比如在Sprint过程中插入突发工作等要求，该如何处理、该如何解决争议呢？相信一定会成为后续Scrum实践者们的热议焦点。 变化5 ——自管理替换自组织：以前版本Scrum指南介绍开发团队是自组织地去选择工作对象以及工作方式。2020年版本更聚焦于Scrum团队，强调一个自管理的Scrum团队，选择工作对象、工作方式以及工作目标。 这个其实有点懒政，从改变的角度并未讲明白自管理和自组织之间的差别是什么，而从指南单独文档角度也没有解释清楚到底自管理意味着啥，也没有讲清楚其争议解决机制是什么，毕竟这三个角色三权鼎力，SM作为事中人是很难以中立角色来协调化解纠纷的。而且更为糟糕的是，在文档中，介绍变化的地方，说的是“a self-managing Scrum Team, choosing who, how, and what to work on”，而在指南正文里面则是“They are also self-managing, meaning they internally decide who does what, when, and how”，两者并不完全一致。这是会带来问题的。Scrum指南或者框架近些年的变化以及创始人们的言论（当然我没有贴身关注他们的动向，所以或许有讲过，但我不知道），给人的感觉是更倾向于减少指导性质的具象化描述，而更强调文化、原则导向与问题解决思路，但在自管理团队的定义方面，如此模糊甚至出现一定程度的自相矛盾，有点匪夷所思。 变化6 ——三个Sprint计划会议议题：2020年版本Scrum指南在“做什么”和“怎么做”基础上，增加强调了Sprint计划会议的第三个议题，也即“为什么”，直指Sprint目标。 加强价值导向，有好有坏。本来团队里就存在挑肥拣瘦的情况，不管创始人们增加这个议题的原意如何，摆在这里就是态度，极有可能会激化冲突。在英文版本中搜索Value也即价值这个词，有25处，但都没有明确定义谁来评判Value，不过蛛丝马迹之间，更主要是指向了PO，这个也可以理解。但我担心这会极大地削弱团队对于工作内容的影响力和决策权。对于研发团队来讲，可能并非好事。 变化7 ——全面简化行文以面向更广大受众：2020年版本Scrum指南着重于消除重复表述及复杂语句，并删除了残留的IT工作化表述语句（例如测试、系统、设计、需求等）。Scrum指南如今只有不到13页的篇幅。 Scrum一直以来都在强调自己不仅仅是适用于IT或研发领域，但毕竟生于此领域，这些改变是好是坏，是数典忘祖还是志在高远，外人不足为道，还是要看两位创始人心中的宏大愿景是啥，他们开心就好。至于广大实践者到底如何感受，过段时间，可能一两年应该就知道了。我？我是觉得不开心的。这份文档叫指南，指南就没有这么简单的。从内容实质来看，改名为指导原则或核心理念都会更合适一些。普适性和实操性是很难去平衡的，至少希望同一份文档能够同时满足普适性和实操性，我觉得要求太高了。完全可以参考我天国做法，既要有规章制度，也要有实施细则。规章制度类似于Scrum框架的核心理念和指导原则，是普适于多种场景的，然后针对不同场景出具实施细则，不就可以了么？ 这个变化的标题“Overall Simplification of Language for a Wider Audience”体现的是作者们的初衷，就是想要去覆盖更广大的受众群体，从这个角度来讲，删除车轱辘话、去IT化表述都是好的变化，是有助于达成这个目标的。 但作为一名主要工作场景仍然是IT或软件研发工作的实践者，我很难说是开心还是难过、满意还是不满意。 附从scrumguides.org官网上下载的2017年的中英文版本，以及2020年的中英文版本。希望前往官网查看的，请点击https://scrumguides.org/download.html。你的敏捷教练/Scrum Master水平如何，来测测吧！直达链接（https://devcloud.huaweicloud.com/expert/open-assessment/qtn?id=62516b50507a44949661689bd7819176）或扫码，了解活动详情赚取福利（https://bbs.huaweicloud.com/forum/thread-86013-1-1.html）。

近小编遇到一个生存问题，女朋友让我给她翻译英文化妆品标签。美其名曰："程序猿每天英语开发,英文一定很好吧，来帮我翻译翻译化妆品成分"，”来，帮我看看这个面膜建议敷几分钟“。。。。看来斥巨资买化妆品不算完，还需要会各种英文介绍。默默收起大学考的一摞429分的四级证书，我打开了IDE。。。我打算开发一个能批量翻译的图片的demo，把家里的各种化妆品都翻译好。机智如我，是不会自己从训练模型做起的，打开有道智云的友好的AI接口页面 ，果然有图片翻译服务，体验了一下可是真不错，于是果断使用。效果展示Demo在这里，一起来看看效果吧：识别过程如下：逐个看看效果哈！make up for ever 虽然没翻译成玫珂菲，哈哈哈但是关键词长期保湿、固定喷雾都翻译出来了~~棒这个更是不明觉厉,韩文、英文混合都能翻译~~~樱花水的表现也不错哦~再乱入一个开起来更像包装盒的图片识别，效果不错，没受图片上文字倾斜等影响 ：调用API的准备工作——生成调用所需要的应用id和密钥根据有道智云的接口约定，需要先在有道智云的个人页面上生成调用所需要的应用id和密钥，以便作为你的调用标识以及收费参考。。具体步骤是：在有道智云的个人页面上创建实例、创建应用、绑定应用和实例，获取调用接口用到的应用的id和密钥。具体个人注册的过程和应用创建过程详见文章分享一次批量文件翻译的开发过程开发过程介绍1、api接口介绍先介绍下该工程的核心部分，有道智云图片翻译服务的调用接口API HTTPS地址：https://openapi.youdao.com/ocrtransapi接口调用方式：POST请求格式：表单相应格式：JSON接口调用参数调用API需要向接口发送以下字段来访问服务。字段名类型含义必填备注typetext文件上传类型True目前支持Base64，请置该字段值为1fromtext源语言True参考下方的 支持语言 (可设置为auto)totext目标语言True参考下方的 支持语言 (可设置为auto)appKeytext应用IDTrue可在 应用管理 查看salttextUUIDTrue1995882C5064805BC30A39829B779D7Bsigntext签名Truemd5(应用Id+q+salt+应用密钥)exttext翻译结果音频格式，支持mp3falsemp3qtext要识别的图片truetype为1时必填,图片的Base64编码docTypetext服务器响应类型，目前只支持jsonfalsejsonrendertext是否需要服务端返回渲染的图片，0：否；1：是，默认是0false0nullIsErrortext如果ocr没有检测到文字，是否返回错误，false：否；true：是，默认是falsefalse注意是字符串签名生成方法如下：1、将请求参数中的 应用ID appKey , 图片的Base64编码 q ,UUID salt 和 应用密钥 按照 应用ID+q+salt+应用密钥的顺序拼接得到字符串 str 。2、对字符串 str 做 md5，得到32位大写的 sign (参考Java生成MD5示例,可点击右侧的JAVA示例)。输出结果返回的结果是json格式，具体说明如下：字段名字段说明orientation图片所对应的方向lanFromocr所识别出来认为的图片中的语言textAngle图片的倾斜角度errorCode错误码lanTo目标语言resRegions图片翻译的具体内容-boundingBox区域范围，四个值： 左上角的x值，左上角的y值，区域的的宽，区域的高 例如：134,0,1066,249-linesCount行数（用于前端排版）-lineheight行高-context该区域的原文-linespace行间距-tranContent翻译结果2、详细开发这个demo使用python3开发，包括maindow.py，transclass.py，pictranslate.py三个文件。maindow.py主要实现界面部分，使用python自带的tkinter库，来进行图片文件选择、选择结果存放路径。transclass.py实现了图片读取、处理等逻辑，最后通过pictranslate.py中的方法来调用图片翻译API。1、界面部分主要元素：123456789101112131415161718root=tk.Tk()root.title("netease youdao translation test")frm = tk.Frame(root)frm.grid(padx='50', pady='50')btn_get_file = tk.Button(frm, text='选择待翻译图片', command=get_files)btn_get_file.grid(row=0, column=0, ipadx='3', ipady='3', padx='10', pady='20')text1 = tk.Text(frm, width='40', height='10')text1.grid(row=0, column=1)btn_get_result_path=tk.Button(frm,text='选择翻译结果路径',command=set_result_path)btn_get_result_path.grid(row=1,column=0)text2=tk.Text(frm,width='40', height='2')text2.grid(row=1,column=1) btn_sure=tk.Button(frm,text="翻译",command=translate_files)btn_sure.grid(row=2,column=1)  root.mainloop()获取待翻译图片文件的方法（此处设置的仅支持.jpg文件）：123456789def get_files(): files = filedialog.askopenfilenames(filetypes=[('text files', '.jpg')]) translate.file_paths=files if files:  for file in files:   text1.insert(tk.END, file + '\n')   text1.update() else:  print('你没有选择任何文件')获取结果存储路径:1234def set_result_path(): result_path=filedialog.askdirectory() translate.result_root_path=result_path text2.insert(tk.END,result_path)翻译按钮，调用了translate_files，该文件中的translate_files()方法最终调用了translate类的translate_files()方法：123456def translate_files(): if translate.file_paths:  translate.translate_files()  tk.messagebox.showinfo("提示","搞定") else :  tk.messagebox.showinfo("提示","无文件")2、批量图片处理transclass.py实现了图片读取、处理等逻辑，Translate类定义如下：12345678910111213141516171819class Translate(): def __init__(self,name,file_paths,result_root_path,trans_type):  self.name=name  self.file_paths=file_paths            # 待翻译文件路径  self.result_root_path=result_root_path # 结果存放路径  self.trans_type=trans_type   def translate_files(self):  for file_path in self.file_paths: #对批量图片逐个处理   file_name=os.path.basename(file_path)   print('==========='+file_path+'===========')   trans_reult=self.translate_use_netease(file_path) #对单个图片调用接口   resul_file=open(self.result_root_path+'/result_'+file_name.split('.')[0]+'.txt','w').write(trans_reult)  #返回结果写入   def translate_use_netease(self,file_content): #调用有道接口，并返回结果  result= connect(file_content)  return result3、有道api调用pictranslate.py中封装了调用有道智云API的一些方法，其中最核心的是connect()方法，按照接口要求拼接了所需参数，发起请求并返回结果。12345678910111213141516171819202122232425262728def connect(file_content,fromLan,toLan): f = open(file_content, 'rb') # 二进制方式打开图文件 q = base64.b64encode(f.read()).decode('utf-8') # 读取文件内容，转换为base64编码 f.close() data = {} # data['from'] = '源语言' # data['to'] = '目标语言' data['from'] = 'auto' data['to'] = 'auto' data['type'] = '1' data['q'] = q salt = str(uuid.uuid1()) signStr = APP_KEY + q + salt + APP_SECRET sign = encrypt(signStr) data['appKey'] = APP_KEY data['salt'] = salt data['sign'] = sign  response = do_request(data) result=json.loads(str(response.content, encoding="utf-8")) print(result)  translateResults=result['resRegions'] print(translateResults) pictransresult="" for i in translateResults:  pictransresult=pictransresult+i['tranContent']+"\n" return pictransresult总结又是一次愉快的开发体验，而且还是为数不多的求生成功体验 : P ，没想到借助开放平台的力量，图像识别，自然语言处理变得如此易如反掌，只要能正确发起请求，就能得到不错的翻译结果，剩下大把的时间用来和女朋友炫技，这感觉——爽！项目地址：https://github.com/LemonQH/BatchPicTranslate

华为鲲鹏动态二进制指令翻译工具(Exagear) 简介: Exagear是华为自研的动态二进制指令翻译工具，通过在运行时，将X86应用的指令翻译为ARM64指令并执行，从而支持Linux X86应用无需重新编译运行在ARM64服务器上，帮助用户将Linux X86无源码应用快速迁移到ARM服务器上，且稳定可靠运行。运行平台： 鲲鹏芯片架构平台服务器，如TaiShan100，TaiShan200等运行操作系统：已兼容openEuler/CentOS/Ubuntu 等linux操作系统 功能特性：1、支持多种部署方式：物理机、虚拟机、容器2、一键式部署：一键式安装部署Exagear软件，X86应用安装和启动与迁移前体验一致3、支持多版本Linux OS：已支持openEuler, CentOS, Ubuntu，其它Linux 发行版本根据用户需求快速开发支持4、性能低损耗：大多数场景的应用，平均性能损耗在20%以内 使用约束：不支持windows应用、驱动和虚拟机类X86系统应用翻译迁移 安装和部署X86应用：说明：1、文中提到的Host是指原生ARM环境，Guest OS是指X86应用运行的OS环境。2、文中假设已经在Host上成功安装Exagear软件。 步骤1：进入Guest OS环境在Host上执行exagear命令，进入X86的Guest OS环境，如下：运行exit命令即可退出Guest OS环境，返回到Host环境。步骤2：安装Linux X86应用： 假设已经将X86应用安装包拷贝到Guest OS环境中，在步骤1中，已经进入Guest OS环境，找到X86应用安装包，执行安装命令，安装完成X86应用。如果需要依赖包，可以通过Guest OS中配置yum或apt源来获取依赖包完成安装。3、运行Linux X86 应用程序成功完成X86应用程序安装后，提供两种方式启动X86应用。方法一：在Guest OS环境中启动，运行Exagear命令进入Guest OS环境后，找到要运行的X86应用，启动方式和在X86系统中一样，直接执行X86的应用启动命令启动X86应用。方法二：在Host环境中启动X86应用，在ARM Host OS命令行下，输入exagear -- x86应用程序，启动X86应用，如：$ exagear -- /usr/sbin/nginx -h或输入X86应用程序二进制文件的完整路径$ /opt/exagear/images/euleros-2.5-x86_64/usr/sbin/nginx -h 欢迎回帖发表您对二进制动态指令翻译工具的建议和疑问哈 ……^V^

一个输入法的交叉翻译软件新版本 A new version of input method cross translation software 中国能否研发一个可以让人们相 互交流的输入法交叉翻译软件新版本吗？Can China research and develop a technology Is there a new version of the interactive input method cross translation software? 有了一个可以让人们单独交流的输入法交叉翻译软件新版本， With a new version of input method cross-translation software that lets people communicate independently, 人们出行就不会受语言障碍阻隔而需要另一个人作为翻译者。 People travel without being blocked by language barriers and need another person as a translator. 输入法交叉翻译软件新版本显示出来的文字， Text displayed in the new version of input method cross translation software， 比如 such as 中英对译显示出来的是上中下英， The Chinese-English translation shows the upper, middle and lower English. 中日对译显示出来的上中下日， The Chinese and Japanese translations show the upper, middle and lower days. 英日对译显示出来的上英下日。 The English and Japanese translations show up on the next day. 也就是输入一种文字显示两种文字。 That is to enter a text to display two kinds of text. 世界文字交叉对译有利于人们交流与认识各国文字， The cross-translation of the world's texts is conducive to people's exchange and understanding of national languages. 适用范围也很广。 The scope of application is also wide. 也可以让人一目了然。 It can also be seen at a glance. 目前的输入法翻译版本只是一对一的对译， The current translation version of the input method is only a one-to-one translation. 让人们对他国文字的认识还有些不方便。 It is still inconvenient for people to understand the writings of other countries. 本输入法交叉翻译软件的新版本可以让人们一目了然的看出对话， The new version of this input method cross translation software can let people see the conversation at a glance, 也对他国文字的认识有所方便。 It is also convenient for the understanding of other languages. 比如 such as 一个懂中文的和两个懂英文的人对话， A Chinese-speaking conversation with two English-speaking people, 用本输入法交叉翻译软件的新版本， New version of cross-translation software using this input method, 三个人直接就可以看出彼此在说什么， Three people can directly see what each other is saying, 而不需要再去找翻译。 You don't need to go find your translation. 注：图片上传不了，本文就是新版本的样板。本版本的诞生将覆盖现有的翻译软件与翻译器，能否诞生就看专业人士了。

几年过去了还没见到它的面世，一个软件带来的利益不明，但它带来的名誉是肯定的。 中国能否研发一个可以让人类相互交流的输入法交叉翻译软件的新版本吗？有了一个可以让人们单独交流的输入法交叉翻译的软件新版本，人们出行就不会受语言障碍阻隔而需要另一个人作为翻译者。输入法交叉翻译的软件新版本显示出来的文字，比如（中英对译显示出来的是上中下英，中日对译显示出来的上中下日，中韩对译显示出来的上中下韩，英韩对译显示出来的上英下韩，日韩对译显示出来的上日下韩，英日对译显示出来的上英下日），也就是输入一种文字显示两种文字。世界文字交叉对译有利于人们交流与认识各国文字，适用范围也很广。目前的输入法翻译版本只是输入一种文字显示一种文字，不方便让人们一目了然的看出对话与认识他国文字。本输入法翻译新版本的诞生将覆盖现有的翻译软件与翻译器。 注：本人头像为软件新版本。

一个输入法的交叉翻译软件新版本 A new version of input method cross translation software 中国能否研发一个可以让人们相 互交流的输入法交叉翻译软件新版本吗？Can China research and develop a technology Is there a new version of the interactive input method cross translation software? 有了一个可以让人们单独交流的输入法交叉翻译软件新版本， With a new version of input method cross-translation software that lets people communicate independently, 人们出行就不会受语言障碍阻隔而需要另一个人作为翻译者。 People travel without being blocked by language barriers and need another person as a translator. 输入法交叉翻译软件新版本显示出来的文字， Text displayed in the new version of input method cross translation software， 比如 such as 中英对译显示出来的是上中下英， The Chinese-English translation shows the upper, middle and lower English. 中日对译显示出来的上中下日， The Chinese and Japanese translations show the upper, middle and lower days. 英日对译显示出来的上英下日。 The English and Japanese translations show up on the next day. 也就是输入一种文字显示两种文字。 That is to enter a text to display two kinds of text. 世界文字交叉对译有利于人们交流与认识各国文字， The cross-translation of the world's texts is conducive to people's exchange and understanding of national languages. 适用范围也很广。 The scope of application is also wide. 也可以让人一目了然。 It can also be seen at a glance. 目前的输入法翻译版本只是一对一的对译， The current translation version of the input method is only a one-to-one translation. 让人们对他国文字的认识还有些不方便。 It is still inconvenient for people to understand the writings of other countries. 本输入法交叉翻译软件的新版本可以让人们一目了然的看出对话， The new version of this input method cross translation software can let people see the conversation at a glance, 也对他国文字的认识有所方便。 It is also convenient for the understanding of other languages. 比如 such as 一个懂中文的和两个懂英文的人对话， A Chinese-speaking conversation with two English-speaking people, 用本输入法交叉翻译软件的新版本， New version of cross-translation software using this input method, 三个人直接就可以看出彼此在说什么， Three people can directly see what each other is saying, 而不需要再去找翻译。 You don't need to go find your translation. 注：本文就是输入法翻译新版本打出来的样板。

几年过去了还没见到它的面世，一个软件带来的利益不明，但它带来的名誉是肯定的。 中国能否研发一个可以让人类相互交流的输入法交叉翻译软件的新版本吗？有了一个可以让人们单独交流的输入法交叉翻译的软件新版本，人们出行就不会受语言障碍阻隔而需要另一个人作为翻译者。输入法交叉翻译的软件新版本显示出来的文字，比如（中英对译显示出来的是上中下英，中日对译显示出来的上中下日，中韩对译显示出来的上中下韩，英韩对译显示出来的上英下韩，日韩对译显示出来的上日下韩，英日对译显示出来的上英下日），也就是输入一种文字显示两种文字。世界文字交叉对译有利于人们交流与认识各国文字，适用范围也很广。目前的输入法翻译版本只是输入一种文字显示一种文字，不方便让人们一目了然的看出对话与认识他国文字。本输入法翻译新版本的诞生将覆盖现有的翻译软件与翻译器。 注：本人头像为软件新版本。

大家好，我是软件开发服务 项目管理服务的产品经理 恒少：）（https://bbs.huaweicloud.com/blogs/adf71fa5bbf811e89fc57ca23e93a89f）作为布道师和产品经理，出差各地接触客户是常态，经常和华为云的客户交流、布道、技术沙龙，但是线下交流，覆盖的用户总还是少数。我希望借华为云社区这个线上的平台，和用户持续交流华为在研发效能提升上的思索和考虑。<恒少出品，必然妥妥干货，必定理论联系实践>，因为软件无银弹，探索始终在路上。-----------------------干货分割线--------------------------------------<001 篇> 我经常出差，接触了大量的华为云的客户，很多客户使用项目管理服务，对Epic都比较陌生，也对如何划分Feature，Story存在疑问为了，我特意整理了一个表格，对每一种工作项类型进行了说明，为了解决很多用户的疑惑，我也增加了样例说明简单一句话：Epic是公司重要战略举措；Feature是对你的用户有价值的功能；Story是分解的细粒度的开发交付的内容，是用户的细分场景；Task是完成需求的过程性的工作。这些术语和概念，来自于业界的共识，对于软件企业，是实现从战略举措到战术执行落地的分层设计。工作项类型说明举例Epic中文通常翻译为史诗，指公司的关键战略举措，可以是重大的业务方向，也可以是重大的技术演讲。企业通过对Epic的发现、定义、投资、管理和落地达成，使得企业的战略投资主题得以落地，并获得相应的市场地位和回报。Epic的粒度比较大，需要分解为Feature，并通过Feature继续分解细化为User Story来完成最终的开发和交付。Epic通常持续数月（months），需要多个迭代才能完成最终的交付。Epic应该对所有研发人员可见，这样可以让研发人员了解他们交付的Story承载怎样的战略举措，让研发人员能更好的理解其工作的价值。Epic通常和公司的经营、竞争力、市场环境紧密相关，举例如下：例1市场差异化：用户体验全面超越竞争对手例2更好的解决方案：新增支持工业互联网的解决方案例3增加收入：产品需要在下个财季增加100万付费用户例4重大技术方向：产品需要全部切换为容器Feature中文通常翻译为特性，代表可以给客户带来价值的产品功能或特性。Feature向上承接Epic，向下分解为User Story。相比Epic，Feature更具体形象，客户可以直接感知，通常在产品发布时作为ReleaseNotes的一部分发布给客户。Feature通常持续数个星期（weeks），需要多个迭代完成交付。Feature应该对客户都有实际的价值，特性的描述通常需要说明对客户的价值，与产品的形态、交付模式有关，举例如下：推荐模板：用户<角色> …希望<结果>… 以便于<目的>例1用户A希望提供导入、导出功能，以便于用户批量整理数据，更高效。例2用户B希望提供超期的邮件通知，以便于用户及时处理任务。例3用户C希望优化鼠标拖动的体验，以便于让用户操作更快。例4用户D希望增加昵称功能，让用户更个性化。Story中文通常翻译为用户故事，User Story的简称。是从用户角度对产品需求的详细描述，更小粒度的功能。Story承接Feature，并放入有优先级的backlog中，持续规划、滚动调整优先级，始终让高优先级的Story更早的交付给客户。优秀的Story应遵循如下的INVEST原则：Independent：每个用户故事应该是独立的，可独立交付给客户。Negotiable：不必非常明确的阐述功能，细节应带到开发阶段跟程序员、客户来共同商议。Valuable：对客户有价值。Estimable：能估计出工作量。Small：要小一点，但不是越小越好，至少在一个迭代中能完成。Testable：可测试。Story通常持续数天（days），并应在一个迭代内完成交付。Story符合INVEST原则，举例如下：推荐模板：用户<角色>…希望<结果>…以便于<目的>例1作为项目经理，希望通过过滤处理人，以便于快速查询指定人的需求。例2作为开发人员，希望将无用的信息进行折叠，以便于减少视觉干扰。例3作为测试人员，希望将测试用例和需求关联，以便于跟踪需求的验证。Task在迭代计划会议中，将纳入迭代的Story指派给具体成员，并分解成一个或多个Task，填写“预计工时”。Task通常为过程性的工作，举例如下：例1开发人员A需要在今天准备好类生产环境。例2开发人员B需要在本周末完成项目组的权限设定。例3开发人员C需要进行代码Review。

英文原文链接：即将到来的内存数据库临界点觉得这篇文章写得确实不错，就利用周末时间完成了翻译，但水平有限，如有翻译不对的请指教。未经同意请勿引用转载    在此，我想花一些时间来讨论内存数据库技术和微软在这个领域的技术路线图。内存数据库技术正在接近数据库行业的颠覆性转折点，这种声音在未来会更加强烈。这些技术已经在重塑分析和报告领域，它们也将越来越多地影响运营和事务处理影响。    首先，快速回顾一下。实际上，所有数据库管理系统（DBMS）都试图将部分数据保留在RAM中。DBMS管理着磁盘与随机存取存储器（RAM）的数据传输，后者被称为“缓冲池”的区域。对于某些情况，您甚至可以分配足够的缓冲池空间从而装载上整个数据库。虽然这可能是对数据库性能有较大诉求的一种可行方法，但它并不是“内存数据库”的含义。    传统的DBMS被设计成支持通常数据比RAM大得多的数据库。而内存数据库通常设计用于支持适合RAM的数据库，而其中许多数据库支持的数据量可能比可用RAM大。内存数据库已存在一段时间了，它们最初用于服务于对性能有较大诉求的电话和金融服务市场。随着围绕内存数据库技术的热度重新抬头，我们开始看到内存数据库管理系统技术在许多场景中逼近了颠覆性的转折点。    当技术演进并在多个方面产生显著的服务改进时，往往会出现破坏性的临界点。通常，颠覆性技术已经存在一段时间，并且在一系列因素趋同之前服务于更多利基场景[2]，以便为更广泛的场景类型实现10倍或更多的改进。比如最近的颠覆性技术事件，非易失性闪存替换MP3播放器等个人电子设备中的硬盘驱动器（HDD）。在这些设备的单代产品中，闪存的成本，容量，功率和改进的物理特性取代了硬盘。当时闪存已经不是新的技术，但当其价格，性能和耐用性综合起来后，使得HDD存储在竞争中处于了劣势。    在本文的其余部分，我们将介绍以下内容：技术趋势促使内存型数据库产生了破坏性的机会。内存数据库技术中使用的设计方法。微软的内存数据库管理系统技术。趋势    过去几十年来，信息技术的进步令人叹为观止。人们设计数据库系统的前景不断变化，因为某些技术组件继续以指数变化方式增长，例如晶体密度遵循着摩尔定律，而其他组件则随是以近线性增长方式增长，例如HDD随机访问时间。当总体考虑这些变化率时，技术要素之间的自然平衡被打破。特别是，硬盘，RAM和CPU的“速度和容量”在过去的10到20年间发生了巨大的变化，驱使我们转向了内存数据库。    大多数数据库系统的设计都是基于无处不在的HDD，它自成立以来一直受到物理限制。特别地，将读/写单元定位在物理介质上的机电元件一直是一个挑战。虽然磁盘传输带宽和容量在过去几十年中呈指数级增长，但将读/写磁头定位在正确位置所花费的时间却提升很少。因此，从磁盘顺序读取的带宽呈现了指数级增长，而在磁盘上随机访问少量数据的性能却几乎没有变化。所以吉姆·格雷--已故的数据库行业先驱之一，挖苦说：“磁盘就是新磁带”。    另一方面，动态RAM（DRAM）自推出以来一直遵循摩尔定律，即它变得越来越便宜，且其容量也快速增加。与硬盘驱动器一样，系统设计人员能够按照指数方式增加进出DRAM的带宽，但延迟，即随机访问单个字节的能力，无法跟上步伐。以CPU处理器周期测量的话，这意味着访问DRAM随机字节的延迟，已经从15到20年前的近一个CPU周期变为现代系统的数百个CPU周期。    摩尔定律虽然仍存在于CPU领域，但设计师却在那里遇到了物理学限制。直到大约5年前，软件开发人员通过更快的时钟速度和改进的CPU架构获得了免费搭便车。不幸的是，CPU功耗相对于时钟速度的增长不是线性的，并且增加的时钟速度使得想保持处理器的元件相对于时钟一致性上遇到了更多的挑战。这迫使CPU设计师将事物保持在一起。更多的功率，更紧密的结合，产生了热管理问题，从根本上否定了不断增加时钟速度的演进方向。由于芯片设计人员仍然有摩尔定律为他们工作，他们可以继续在CPU芯片上放置更多的晶体管，这些晶体管需要以某种方式使用。结果，正如我们在过去几年中所经历的那样，更多的处理器内核，更多的板载缓存以及更专用的功能和指令。所有这些新的CPU晶体管都可以很好地用于内存数据库场景，但它们需要一种新的设计方法。    所有这些变化的一个共同特点是带宽和容量往往比延迟减少更快[1]。延迟往往会影响我们的机电前端，例如硬盘驱动器寻道时间，以及影响网络的光物理速度，DRAM延迟等。    要真正了解动态，我们需要从相对的角度来看待这些元素：CPU正在获得更多的晶体管，但它们被用于多核和专用功能。因此，CPU可以执行大量工作 - 如果我们能够提供足够保持CPU忙碌的数据。这是以数据为中心的处理系统（如数据库系统）的主要挑战。DRAM变得越来越大，系统设计人员正在努力保持CPU和DRAM带宽之间的匹配，不至于浪费计算资源。正如Jim Gray所说，“磁盘是新磁带”。它们是储存大量相对冷数据的地方。    实际上，一切都在进一步分化。今天，需要100个处理器周期才能从DRAM中随机获取一个字节，需要数百万个周期来随机访问硬盘上的字节。在面对这些变化时，创建高性能系统的方法有2种：1）使其它组件更接近CPU以减少延迟，2）尽可能多地传输数据，因为带宽是足够的，而延迟达到了物理学上的限制。这些在数据库世界之外的因素，正在促使数据库实施者重新思考他们几十年来使用的设计方法。内存数据库设计方法：    我将简要介绍内存数据库系统设计人员使用的几种架构模式。要完全描述我所描述的架构模式的话，可以写成一本书，所以这里我只是简要着重描述下与更传统的数据库技术的差异。压缩    许多内存数据库系统采用某种形式的数据压缩。这有助于在相对稀缺且相对昂贵的 DRAM中保存更多数据。对数据进行解压（必要时）以对其进行操作确实需要花费处理器周期，但是对比从磁盘获取未压缩数据可能需要数百万个处理器周期，当前将更多压缩数据保留在RAM中，然后花费一些CPU周期来解压这些数据很有意义的。数据结构和算法    基础数据库算法正在修订以支持内存数据库需求。一种称为基于列的存储的方法在现代系统上特别强大。大多数传统数据库系统将数据存储在记录或行中。在这些系统中，一条员工记录可能包含名字，姓氏，员工ID等，这些属性将全部存储在磁盘和内存中。基于列的方法存储各个属性的所有值，例如员工ID，上次雇用日期，姓氏，或者存储是在磁盘上或者存储在内存中。鉴于这种结构，如果它们全部分开存储的话，您可能会问我们如何将“John Doe”的全部属性重新组合在一起显示出来？答案是每个属性（列）通常都有一个隐式序号。具体来说，如果John Doe是数据库中的第56位记录，我们可以找到每个列存储集中的第56位的条目，并获取John Doe的详细信息。    那么列存储如何帮助我们呢？假设我们想找到去年雇用的所有员工。查找这些员工意味着搜索“最后雇用日期”列。由于我们将所有list-hire-date值放在一起并且可能进行了压缩，因此存储此属性的数据结构非常密集 - 它只包含我们进行搜索所需的数据而不必涉及通过名字和姓氏等等。由于我不会进入这里的原因，现代CPU在扫描密集数据结构时性能特别高。关于压缩; 假设我们的员工拥有三种状态 - 活动，休假或终止。如果我们使用一个字节来表示这个值，则这三个状态可以用2位而不是8位表示。再假设我们有1200名员工，其中1104名是“活跃”的。如果我们对员工进行分区或排序，可以使用称为“游程编码”[3]的方案，注意到'接下来的1104名员工都具有“活动”的价值，所以可以以非常紧凑的方式代表所有1104名活跃员工。在基于列的存储还有其他更新奇的压缩方案，这些简单的例子仅为了说明下思路。    列的存储也适用于多核处理器。假设我们想找到所有最后雇用日期在18个月之内的辞职雇员。为了实现这个查询，我们可以让一个cpu核查找所有已辞职的员工，另一个cpu核找到满足查询雇用日期的员工。然后找到这2部分记录的交集即可，而这件事情非常地简单。建模的作用    基于列的存储技术很适合分析领域，就像我们上一节举得例子那样。这些一直是多维OLAP（MOLAP）产品的领域，例如SQL Server Analysis Services的原始形式。传统的MOLAP产品需要定义逻辑模型，以便可以预先计算聚合，例如每季度的销售额或每个区域的销售额。逻辑模型指定了数据的信息模型和问题类型。逻辑模型也可以作为物理数据模型的框架，例如预先计算和预聚合数据以支持多维度查询。内存数据库技术不需要预先计算聚合和创建其他形式的索引。利用内存数据库技术，逻辑模型可以很好地满足业务域的需求发展，而无需更新物理模型。这种组合使业务分析师能够创建满足业务需求的逻辑模型，而无需成为MOLAP产品所需的物理设计方面的专家。这样可以提高灵活性，并且是Microsoft自助式托管BI方法的基础部分。这种组合使业务分析师能够创建满足业务需求的逻辑模型，而无需成为MOLAP产品所需的物理设计方面的专家。这样可以提高灵活性，并且是Microsoft自助式托管BI方法的基础部分。微软在做什么？    一段时间以来，微软一直在投入和推动内存数据库技术。我们已经研发一个基于列的存储引擎，它作为Microsoft Excel 的“ PowerPivot ”加载项的一部分提供。在SQL Server 2012中，它作为SQL Server Analysis Services的一部分作为xVelocity内存分析引擎提供。集成到SQL Server RDBMS服务器中的同一引擎作为xVelocity内存优化列存储索引提供。此列存储索引也将进入我们的并行数据仓库产品。通过使用这种新的内存优化列存储索引类型，一个SQL Server 2012客户能够实现200倍的加速。你可以在这里阅读并研究相关案例。    除了明显的性能提升之外，使用通用引擎还有许多优点。在Power Pivot和Analysis Services的情况下，有一种通用的数据分析表达式语言，称为DAX，它允许分析查询以相同的方式在Excel，Excel Services或SQL Server Analysis Services中运行。这非常有价值，因为它允许基于Microsoft Excel的业务分析模型同样运行在基于服务器的Analysis Services中。在SQL Server 2012 Analysis Services中，有一个新工具允许您非常轻松地将基于Excel的PowerPivot解决方案升级为基于服务器的Analysis Services解决方案。这允许在Excel中以自助式方法开发分析解决方案，然后根据需要轻松转换为托管IT解决方案。    我们在这篇文章中介绍的大部分内容都是基于列的内存引擎，专为分析和数据仓库领域而设计 - 这是我们多年来一直在推动。虽然基于列的存储对于这些场景非常有用，但它们对于以一次**，修改或读取单个或少量记录为特征的事务处理领域而言并非最佳。当使用基于列的存储模型组合来自多个属性的单个记录时，通常比基于行的存储模型更代价更大。虽然目前基于内存数据库技术的大部分成功案例都是通过基于列的存储来实现分析领域的需求，但内存中的优化方法也适用于基于行的事务处理领域。微软对这里领域也进行了投入，与客户进行了实验,取得了对现有事务处理任务超过10倍的加速——在未来还会有更高的提升。    内存数据库技术取得了令人难以置信的进步，但当这些功能方法作为完整数据平台的一部分来整合和交付时，最终会让客户获得最高的价值。“基础”（管理，安全，信息治理）方面的好处，以及如何使现有和新应用程序更容易使用这些功能。就我们迄今为止所做的工作而言，通过作为关系引擎的索引，集成到Analysis服务中并使用PowerPivot为Excel用户提供体验，我们可以轻松地对现有应用程序进行扩展，并实现整体桌面上的自助商业智能等新方案。总结    一系列尖端信息技术的技术的发展正在为一个临界点创造条件，在这个临界点，在未来5 - 10年内内存数据库技术将会普遍应用。由数字事实或数字可编码维度的以读取主要查询主导的分析领域，内存数据库技术会被优先广泛采用。随着时间的推移，内存数据库技术也将应用于事务处理领域。    您可能会听到有关内存数据库技术的更多信息。在Microsoft，我们相信这个技术的转折点，并且已经在Microsoft Excel Power Pivot和SQL Server Analysis Services中运行内存数据库技术一段时间了。随着SQL Server 2012的推出，核心关系数据库引擎也将使用我们的内存数据库技术作为基于列存储的索引。使用这种基于新列的索引的关系数据仓库的客户正在使用这种新功能进行广泛的查询，获得了令人难以置信的加速。    微软还在研发其他内存数据库技术，这些技术随着技术和机遇的成熟而发布。为了体验即将发生的事情，我们正在实验室中开发内存数据库解决方案，并构建我们的真实场景以展示其潜力。其中一个基于微软在线服务业务的场景包含一个1000亿行的事实表。在这种情况下，我们执行三次计算 - 总计3000亿次计算，查询响应时间为1/3秒。此实现中没有用户定义的聚合; 我们实际上实时扫描压缩列存储。    在内存数据库技术中，对于构建这些系统的人员和使用它们的客户来说，这是一个激动人心的时刻。我代表SQL Server产品工程团队，希望您有机会使用我们的内存数据库技术来解决您自己组织中的新挑战。Dave Campbell 技术研究员 Microsoft SQL Server[1] David A. Patterson。延迟滞后于带宽。ACM第47卷第10期（2004年10月），第71-75页。[2] 利基市场：大家可参考wiki的定位，我看了几遍理解了一个大概。https://zh.wikipedia.org/wiki/%E5%88%A9%E5%9F%BA%E5%B8%82%E5%9C%BA[3] 游程编码：维基百科说明 https://zh.wikipedia.org/wiki/%E6%B8%B8%E7%A8%8B%E7%BC%96%E7%A0%81

本帖最后由 想要偷渡的非酋 于 2017-12-20 16:21 编辑一、界面本地化的步骤方法 1、进入到“setup”->“Display”界面设置语言为中文即可 另外dolibarr还支持翻译纠正功能，可以在“setup”->“Translation”中填写正确的翻译用以纠正系统中的某些不友好翻译：例如设置语言为zh_CN，key为Dashboard，翻译为仪表盘，那么Dashboard刷新后就会展示成仪表盘