MethodHandles 还是 LambdaMetafactory?
MethodHandles or LambdaMetafactory?
在我的工作中,我们有一个用于指定数学公式的 DSL,我们后来将其应用于很多点(以百万计)。
截至今天,我们构建了公式的 AST,并访问每个节点以生成我们所说的 "Evaluator"。然后,我们将公式的参数传递给该评估器,并针对每个点进行计算。
例如,我们有这个公式:x * (3 + y)
┌────┐
┌─────┤mult├─────┐
│ └────┘ │
│ │
┌──v──┐ ┌──v──┐
│ x │ ┌───┤ add ├──┐
└─────┘ │ └─────┘ │
│ │
┌──v──┐ ┌──v──┐
│ 3 │ │ y │
└─────┘ └─────┘
我们的评估器将为每个步骤发出 "Evaluate" 个对象。
这种方法编程容易,但效率不高。
所以我开始研究方法句柄以构建一个 "composed" 方法句柄来加快最近的速度。
一些事情:我有我的 "Arithmetic" class 和:
public class Arithmetics {
public static double add(double a, double b){
return a+b;
}
public static double mult(double a, double b){
return a*b;
}
}
并且在构建我的 AST 时,我使用 MethodHandles.lookup() 来直接处理它们并组合它们。沿着这些思路,但是在树中:
Method add = ArithmeticOperator.class.getDeclaredMethod("add", double.class, double.class);
Method mult = ArithmeticOperator.class.getDeclaredMethod("mult", double.class, double.class);
MethodHandle mh_add = lookup.unreflect(add);
MethodHandle mh_mult = lookup.unreflect(mult);
MethodHandle mh_add_3 = MethodHandles.insertArguments(mh_add, 3, plus_arg);
MethodHandle formula = MethodHandles.collectArguments(mh_mult, 1, mh_add_3); // formula is f(x,y) = x * (3 + y)
遗憾的是,我对结果感到非常失望。
例如,方法句柄的实际构造非常长(由于调用 MethodHandles::insertArguments 和其他此类组合函数),并且为评估增加的加速仅在超过 600k 次迭代后才开始产生影响。
在 10M 次迭代时,方法句柄开始真正发挥作用,但数百万次迭代还不是(还?)典型用例。我们大约在 10k-1M 左右,结果好坏参半。
此外,实际计算速度加快了,但速度没有那么快(~2-10 倍)。我期待 运行 快一点..
所以无论如何,我又开始搜索 Whosebug,看到了像这样的 LambdaMetafactory 线程:
我很想开始尝试这个。但在此之前,我希望您能就一些问题发表意见:
我需要能够编写所有这些 lambda。 MethodHandles 提供了很多(缓慢的,诚然)方法来做到这一点,但我觉得 lambdas 有更严格的 "interface",我还不能确定如何做到这一点。你知道怎么做吗?
lambda 表达式和方法句柄相互关联,我不确定我是否会获得显着的加速。我看到了简单 lambda 的这些结果:direct: 0,02s, lambda: 0,02s, mh: 0,35s, reflection: 0,40
但是复合 lambda 呢?
谢谢大家!
我认为,对于大多数实际情况,由满足特定接口的节点组成的不可变评估树或从公共评估器库继承的节点 class 是无与伦比的。 HotSpot 能够执行(积极的)内联,至少对于子树,但可以自由决定内联多少节点。
相比之下,为整个树生成显式代码会带来超过 JVM 阈值的风险,然后,您的代码肯定没有分派开销,但可能 运行 一直被解释.
适应的 MethodHandle
树像任何其他树一样开始,但开销更高。它自己的优化是否能够击败 HotSpots 自己的内联策略,是值得商榷的。正如您所注意到的,在自调整开始之前需要大量调用。看起来,对于组合方法句柄,阈值以一种不幸的方式累积。
举一个评估树模式的突出例子,当你使用 Pattern.compile
准备正则表达式匹配操作时,不会生成字节码或本机代码,尽管方法名称可能会误导人们这样想方向。内部表示只是一个不可变的节点树,表示不同类型操作的组合。由 JVM 优化器在认为有益的地方为其生成扁平化代码。
Lambda 表达式不会改变游戏规则。它们允许您生成(小的)classes 来实现接口并调用目标方法。您可以使用它们来构建一个不可变的评估树,虽然这不太可能与显式编程的评估节点 classes 有不同的性能,但它允许更简单的代码:
public class Arithmetics {
public static void main(String[] args) {
// x * (3 + y)
DoubleBinaryOperator func=op(MUL, X, op(ADD, constant(3), Y));
System.out.println(func.applyAsDouble(5, 4));
PREDEFINED_UNARY_FUNCTIONS.forEach((name, f) ->
System.out.println(name+"(0.42) = "+f.applyAsDouble(0.42)));
PREDEFINED_BINARY_FUNCTIONS.forEach((name, f) ->
System.out.println(name+"(0.42,0.815) = "+f.applyAsDouble(0.42,0.815)));
// sin(x)+cos(y)
func=op(ADD,
op(PREDEFINED_UNARY_FUNCTIONS.get("sin"), X),
op(PREDEFINED_UNARY_FUNCTIONS.get("cos"), Y));
System.out.println("sin(0.6)+cos(y) = "+func.applyAsDouble(0.6, 0.5));
}
public static DoubleBinaryOperator ADD = Double::sum;
public static DoubleBinaryOperator SUB = (a,b) -> a-b;
public static DoubleBinaryOperator MUL = (a,b) -> a*b;
public static DoubleBinaryOperator DIV = (a,b) -> a/b;
public static DoubleBinaryOperator REM = (a,b) -> a%b;
public static <T> DoubleBinaryOperator op(
DoubleUnaryOperator op, DoubleBinaryOperator arg1) {
return (x,y) -> op.applyAsDouble(arg1.applyAsDouble(x,y));
}
public static DoubleBinaryOperator op(
DoubleBinaryOperator op, DoubleBinaryOperator arg1, DoubleBinaryOperator arg2) {
return (x,y)->op.applyAsDouble(arg1.applyAsDouble(x,y),arg2.applyAsDouble(x,y));
}
public static DoubleBinaryOperator X = (x,y) -> x, Y = (x,y) -> y;
public static DoubleBinaryOperator constant(double value) {
return (x,y) -> value;
}
public static final Map<String,DoubleUnaryOperator> PREDEFINED_UNARY_FUNCTIONS
= getPredefinedFunctions(DoubleUnaryOperator.class,
MethodType.methodType(double.class, double.class));
public static final Map<String,DoubleBinaryOperator> PREDEFINED_BINARY_FUNCTIONS
= getPredefinedFunctions(DoubleBinaryOperator.class,
MethodType.methodType(double.class, double.class, double.class));
private static <T> Map<String,T> getPredefinedFunctions(Class<T> t, MethodType mt) {
Map<String,T> result=new HashMap<>();
MethodHandles.Lookup l=MethodHandles.lookup();
for(Method m:Math.class.getMethods()) try {
MethodHandle mh=l.unreflect(m);
if(!mh.type().equals(mt)) continue;
result.put(m.getName(), t.cast(LambdaMetafactory.metafactory(
MethodHandles.lookup(), "applyAsDouble", MethodType.methodType(t),
mt, mh, mt) .getTarget().invoke()));
}
catch(RuntimeException|Error ex) { throw ex; }
catch(Throwable ex) { throw new AssertionError(ex); }
return Collections.unmodifiableMap(result);
}
}
这是为由 java.lang.Math
中的基本算术运算符和函数组成的表达式编写求值器所需的一切,后者是动态收集的,以解决您问题的那个方面。
请注意,从技术上讲,
public static DoubleBinaryOperator MUL = (a,b) -> a*b;
只是
的缩写
public static DoubleBinaryOperator MUL = Arithmetics::mul;
public static double mul(double a, double b){
return a*b;
}
我添加了一个包含一些示例的 main
方法。请记住,这些函数在第一次调用时表现得像编译代码,事实上,它们仅由编译代码组成,但由多个函数组成。
在我的工作中,我们有一个用于指定数学公式的 DSL,我们后来将其应用于很多点(以百万计)。
截至今天,我们构建了公式的 AST,并访问每个节点以生成我们所说的 "Evaluator"。然后,我们将公式的参数传递给该评估器,并针对每个点进行计算。
例如,我们有这个公式:x * (3 + y)
┌────┐
┌─────┤mult├─────┐
│ └────┘ │
│ │
┌──v──┐ ┌──v──┐
│ x │ ┌───┤ add ├──┐
└─────┘ │ └─────┘ │
│ │
┌──v──┐ ┌──v──┐
│ 3 │ │ y │
└─────┘ └─────┘
我们的评估器将为每个步骤发出 "Evaluate" 个对象。
这种方法编程容易,但效率不高。
所以我开始研究方法句柄以构建一个 "composed" 方法句柄来加快最近的速度。
一些事情:我有我的 "Arithmetic" class 和:
public class Arithmetics {
public static double add(double a, double b){
return a+b;
}
public static double mult(double a, double b){
return a*b;
}
}
并且在构建我的 AST 时,我使用 MethodHandles.lookup() 来直接处理它们并组合它们。沿着这些思路,但是在树中:
Method add = ArithmeticOperator.class.getDeclaredMethod("add", double.class, double.class);
Method mult = ArithmeticOperator.class.getDeclaredMethod("mult", double.class, double.class);
MethodHandle mh_add = lookup.unreflect(add);
MethodHandle mh_mult = lookup.unreflect(mult);
MethodHandle mh_add_3 = MethodHandles.insertArguments(mh_add, 3, plus_arg);
MethodHandle formula = MethodHandles.collectArguments(mh_mult, 1, mh_add_3); // formula is f(x,y) = x * (3 + y)
遗憾的是,我对结果感到非常失望。 例如,方法句柄的实际构造非常长(由于调用 MethodHandles::insertArguments 和其他此类组合函数),并且为评估增加的加速仅在超过 600k 次迭代后才开始产生影响。
在 10M 次迭代时,方法句柄开始真正发挥作用,但数百万次迭代还不是(还?)典型用例。我们大约在 10k-1M 左右,结果好坏参半。
此外,实际计算速度加快了,但速度没有那么快(~2-10 倍)。我期待 运行 快一点..
所以无论如何,我又开始搜索 Whosebug,看到了像这样的 LambdaMetafactory 线程:
我很想开始尝试这个。但在此之前,我希望您能就一些问题发表意见:
我需要能够编写所有这些 lambda。 MethodHandles 提供了很多(缓慢的,诚然)方法来做到这一点,但我觉得 lambdas 有更严格的 "interface",我还不能确定如何做到这一点。你知道怎么做吗?
lambda 表达式和方法句柄相互关联,我不确定我是否会获得显着的加速。我看到了简单 lambda 的这些结果:
direct: 0,02s, lambda: 0,02s, mh: 0,35s, reflection: 0,40
但是复合 lambda 呢?
谢谢大家!
我认为,对于大多数实际情况,由满足特定接口的节点组成的不可变评估树或从公共评估器库继承的节点 class 是无与伦比的。 HotSpot 能够执行(积极的)内联,至少对于子树,但可以自由决定内联多少节点。
相比之下,为整个树生成显式代码会带来超过 JVM 阈值的风险,然后,您的代码肯定没有分派开销,但可能 运行 一直被解释.
适应的 MethodHandle
树像任何其他树一样开始,但开销更高。它自己的优化是否能够击败 HotSpots 自己的内联策略,是值得商榷的。正如您所注意到的,在自调整开始之前需要大量调用。看起来,对于组合方法句柄,阈值以一种不幸的方式累积。
举一个评估树模式的突出例子,当你使用 Pattern.compile
准备正则表达式匹配操作时,不会生成字节码或本机代码,尽管方法名称可能会误导人们这样想方向。内部表示只是一个不可变的节点树,表示不同类型操作的组合。由 JVM 优化器在认为有益的地方为其生成扁平化代码。
Lambda 表达式不会改变游戏规则。它们允许您生成(小的)classes 来实现接口并调用目标方法。您可以使用它们来构建一个不可变的评估树,虽然这不太可能与显式编程的评估节点 classes 有不同的性能,但它允许更简单的代码:
public class Arithmetics {
public static void main(String[] args) {
// x * (3 + y)
DoubleBinaryOperator func=op(MUL, X, op(ADD, constant(3), Y));
System.out.println(func.applyAsDouble(5, 4));
PREDEFINED_UNARY_FUNCTIONS.forEach((name, f) ->
System.out.println(name+"(0.42) = "+f.applyAsDouble(0.42)));
PREDEFINED_BINARY_FUNCTIONS.forEach((name, f) ->
System.out.println(name+"(0.42,0.815) = "+f.applyAsDouble(0.42,0.815)));
// sin(x)+cos(y)
func=op(ADD,
op(PREDEFINED_UNARY_FUNCTIONS.get("sin"), X),
op(PREDEFINED_UNARY_FUNCTIONS.get("cos"), Y));
System.out.println("sin(0.6)+cos(y) = "+func.applyAsDouble(0.6, 0.5));
}
public static DoubleBinaryOperator ADD = Double::sum;
public static DoubleBinaryOperator SUB = (a,b) -> a-b;
public static DoubleBinaryOperator MUL = (a,b) -> a*b;
public static DoubleBinaryOperator DIV = (a,b) -> a/b;
public static DoubleBinaryOperator REM = (a,b) -> a%b;
public static <T> DoubleBinaryOperator op(
DoubleUnaryOperator op, DoubleBinaryOperator arg1) {
return (x,y) -> op.applyAsDouble(arg1.applyAsDouble(x,y));
}
public static DoubleBinaryOperator op(
DoubleBinaryOperator op, DoubleBinaryOperator arg1, DoubleBinaryOperator arg2) {
return (x,y)->op.applyAsDouble(arg1.applyAsDouble(x,y),arg2.applyAsDouble(x,y));
}
public static DoubleBinaryOperator X = (x,y) -> x, Y = (x,y) -> y;
public static DoubleBinaryOperator constant(double value) {
return (x,y) -> value;
}
public static final Map<String,DoubleUnaryOperator> PREDEFINED_UNARY_FUNCTIONS
= getPredefinedFunctions(DoubleUnaryOperator.class,
MethodType.methodType(double.class, double.class));
public static final Map<String,DoubleBinaryOperator> PREDEFINED_BINARY_FUNCTIONS
= getPredefinedFunctions(DoubleBinaryOperator.class,
MethodType.methodType(double.class, double.class, double.class));
private static <T> Map<String,T> getPredefinedFunctions(Class<T> t, MethodType mt) {
Map<String,T> result=new HashMap<>();
MethodHandles.Lookup l=MethodHandles.lookup();
for(Method m:Math.class.getMethods()) try {
MethodHandle mh=l.unreflect(m);
if(!mh.type().equals(mt)) continue;
result.put(m.getName(), t.cast(LambdaMetafactory.metafactory(
MethodHandles.lookup(), "applyAsDouble", MethodType.methodType(t),
mt, mh, mt) .getTarget().invoke()));
}
catch(RuntimeException|Error ex) { throw ex; }
catch(Throwable ex) { throw new AssertionError(ex); }
return Collections.unmodifiableMap(result);
}
}
这是为由 java.lang.Math
中的基本算术运算符和函数组成的表达式编写求值器所需的一切,后者是动态收集的,以解决您问题的那个方面。
请注意,从技术上讲,
public static DoubleBinaryOperator MUL = (a,b) -> a*b;
只是
的缩写public static DoubleBinaryOperator MUL = Arithmetics::mul;
public static double mul(double a, double b){
return a*b;
}
我添加了一个包含一些示例的 main
方法。请记住,这些函数在第一次调用时表现得像编译代码,事实上,它们仅由编译代码组成,但由多个函数组成。