文档章节

Go1.1性能测试报告(和C差距在10%以内)

chai2010
 chai2010
发布于 2013/05/14 18:01
字数 2026
阅读 25756
收藏 51

<!-- Go1.1性能测试报告(和C差距在10%以内) -->

<!-- http://blog.golang.org/2011/06/profiling-go-programs.html -->

最近Go1.1正式发布, 根据官方的说法, Go1.1性能比Go1.0提升基本有30%-40%, 有时更多(当然也有不明显的情况).

Go1.1的详细介绍: Go1.1新特性介绍(语言和库更完善/性能提高约30%).

这里是针对Go1.1和C语言的性能测试: 测试的重点是语言的性能, 当然也会受到标准库性能的影响.

测试环境

补充: i7-3770是4核心8线程.

gccgc版本:

gcc -v
gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)

go version
go version go1.1 linux/amd64

测试结果

$GOROOT/test/bench/shootout/timing.sh
fasta -n 25000000
	gcc -m64 -O2 fasta.c              0.86u 0.00s 0.87r
	gc fasta                          0.85u 0.00s 0.86r
	gc_B fasta                        0.83u 0.00s 0.83r

reverse-complement < output-of-fasta-25000000
	gcc -m64 -O2 reverse-complement.c 0.45u 0.05s 0.50r
	gc reverse-complement             0.60u 0.05s 0.65r
	gc_B reverse-complement           0.55u 0.04s 0.59r

nbody -n 50000000
	gcc -m64 -O2 nbody.c -lm          5.51u 0.00s 5.52r
	gc nbody                          7.16u 0.00s 7.18r
	gc_B nbody                        7.12u 0.00s 7.14r

binary-tree 15 # too slow to use 20
	gcc -m64 -O2 binary-tree.c -lm    0.31u 0.00s 0.31r
	gc binary-tree                    1.08u 0.00s 1.07r
	gc binary-tree-freelist           0.15u 0.00s 0.15r

fannkuch 12
	gcc -m64 -O2 fannkuch.c           26.45u 0.00s 26.54r
	gc fannkuch                       35.99u 0.00s 36.08r
	gc fannkuch-parallel              73.40u 0.00s 18.58r
	gc_B fannkuch                     25.18u 0.00s 25.25r

regex-dna 100000
	gcc -m64 -O2 regex-dna.c -lpcre   0.25u 0.00s 0.26r
	gc regex-dna                      1.65u 0.00s 1.66r
	gc regex-dna-parallel             1.72u 0.01s 0.67r
	gc_B regex-dna                    1.64u 0.00s 1.65r

spectral-norm 5500
	gcc -m64 -O2 spectral-norm.c -lm  9.63u 0.00s 9.66r
	gc spectral-norm                  9.63u 0.00s 9.66r
	gc_B spectral-norm                9.63u 0.00s 9.66r

k-nucleotide 1000000
	gcc -O2 k-nucleotide.c -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -lglib-2.0  2.62u 0.00s 2.63r
	gc k-nucleotide                   2.69u 0.01s 2.71r
	gc k-nucleotide-parallel          3.02u 0.00s 0.97r
	gc_B k-nucleotide                 2.66u 0.01s 2.68r

mandelbrot 16000
	gcc -m64 -O2 mandelbrot.c        20.95u 0.00s 21.01r
	gc mandelbrot                    23.73u 0.00s 23.79r
	gc_B mandelbrot                  23.72u 0.00s 23.79r

meteor 2098
	gcc -m64 -O2 meteor-contest.c     0.05u 0.00s 0.05r
	gc meteor-contest                 0.06u 0.00s 0.07r
	gc_B meteor-contest               0.06u 0.00s 0.06r

pidigits 10000
	gcc -m64 -O2 pidigits.c -lgmp     0.77u 0.00s 0.77r
	gc pidigits                       1.45u 0.01s 1.44r
	gc_B pidigits                     1.45u 0.01s 1.43r

threadring 50000000
	gcc -m64 -O2 threadring.c -lpthread     12.05u 261.20s 216.36r
	gc threadring                           6.61u 0.00s 6.63r

chameneos 6000000
	gcc -m64 -O2 chameneosredux.c -lpthread 4.04u 21.08s 4.20r
	gc chameneosredux                       4.97u 0.00s 4.99r

测试结果说明

其中gc_B是开了-B选项, 选项的说明如下:

go tool 6g -h
usage: 6g [options] file.go...
  -+    compiling runtime
  -%    debug non-static initializers
  -A    for bootstrapping, allow 'any' type
  -B    disable bounds checking
...

应该就是禁用了Go的slice下标越界检测等特性.

测试的结果显示Go的性能已经和C语言已经非常接近了, 有极个别的场景甚至比C还好(binary-tree).

根据$GOROOT/test/bench/shootout/timing.log的数据, gccgo 的优化应该更好一点.

不过目前gccgo的标准库比gc标准库可能要差一些(gccgo1.1还未发布), 因此有些测试性能比gc差一些.

我电脑没有安装gccgo, 因此只有gcc/gc/gc_B三个测试结果.

关于 BenchmarksGame 的测试差异

http://benchmarksgame.alioth.debian.org/u64q/go.php

说明: BenchmarksGame 不是为了测试不同语言的最优性能, 而且为了测试不同语言最自然状态下编写程序的性能. 比如, binary-trees测试就是禁止自己定制专有的缓冲池的, 而C语言的版本则可以随意使用 各种优化手段(基于apr和缓冲池和openmp的并行优化).

BenchmarksGame的测试结果中, 有几个Go的性能很差(已经提交了spectral-norm的优化版本):

Benchmark      Time Memory   Code
fasta           3×    3×      ±
spectral-norm   4×    3×      ±
binary-trees   13×    4×      ±
regex-dna †    26×    ±      1/4

补充: BenchmarksGame 测试的是程序实际运行时间, GoBench 是测试的CPU时间. 如果 GoBench 要减少实际时间, 需要充分利用多个CPU的运算资源(Go测试代码对多CPU的性能还有待进一步分析).

补充: BenchmarksGamebinary-trees测试禁止自己定制专有的缓冲池. 因此, 只能寄希望于Go的GC性能改进或新的sync.Cache能尽快发布.

为了方便比较, 在同一台机器上对比了 BenchmarksGameGoBench 的测试结果 .

完整测试代码在: https://bitbucket.org/chai2010/gobench

spectral-norm.go的优化

Go自带的spectral-norm测试性能比BenchmarksGame的性能要低.

我对spectral-norm的代码进行了优化, 优化之后的性能比BenchmarksGame要好一些.

优化前的代码(spectral-norm.go):

func evalA(i, j int) float64 { return 1 / float64(((i+j)*(i+j+1)/2 + i + 1)) }
v[i] += evalA(i, j) * u[j]

函数evalA将整数表达式先转换为float64, 然后做了一次倒数运算. 其中倒数的运算有一定冗余.

优化后的代码(chai2010-spectral-norm.go):

func evalA(i, j int) int { return ((i+j)*(i+j+1)/2 + i + 1) }
v[i] += u[j] / float64(evalA(i, j))

只在必要的时候才做浮点的转换, 减少了一次倒数的运算.

测试时间由 9.62u 减少到 4.35u, 性能提高约1倍.

完整的对比结果如下:

./timing.sh
fasta -n 25000000
	gcc -m64 -O3 -fomit-frame-pointer -march=native -mfpmath=sse -msse3 alioth-fasta.gcc-2.c   0.96u 0.18s 1.15r
	gcc -m64 -O3 alioth-fasta.gcc-2.c       0.92u 0.22s 1.15r
	gcc -m64 -O2 alioth-fasta.gcc-2.c       0.99u 0.15s 1.15r
	gc alioth-fasta 3.04u 0.00s 3.06r
	gc_B alioth-fasta       3.03u 0.00s 3.04r
	gcc -m64 -O3 fasta.c    0.87u 0.00s 0.87r
	gcc -m64 -O2 fasta.c    0.86u 0.00s 0.87r
	gc fasta        0.85u 0.00s 0.86r
	gc_B fasta      0.83u 0.00s 0.83r

spectral-norm 5500
	g++ -m64 -O3 -march=native -fopenmp -mfpmath=sse -msse2 alioth-spectralnorm.gpp-2.cpp   4.69u 0.00s 0.59r
	g++ -m64 -O2 -march=native -fopenmp -mfpmath=sse -msse2 alioth-spectralnorm.gpp-2.cpp   4.69u 0.00s 0.59r
	gc alioth-spectralnorm  6.75u 0.00s 1.67r
	gc_B alioth-spectralnorm        6.93u 0.00s 1.69r
	gcc -m64 -O2 spectral-norm.c -lm        9.63u 0.00s 9.66r
	gc spectral-norm        9.62u 0.00s 9.65r
	gc_B spectral-norm      9.62u 0.00s 9.66r
	gc spectral-norm-parallel       9.86u 0.00s 4.91r
	gc_B spectral-norm-parallel     9.85u 0.00s 4.90r
	gc chai2010-spectral-norm       4.35u 0.00s 4.36r
	gc_B chai2010-spectral-norm     4.35u 0.00s 4.36r
	gc chai2010-spectral-norm-parallel      5.15u 0.00s 2.21r
	gc_B chai2010-spectral-norm-parallel    4.58u 0.00s 2.22r

binary-tree 15 # too slow to use 20
	gcc -m64 -O3 -fomit-frame-pointer -march=native -fopenmp -I/usr/include/apr-1 -lapr-1 -lgomp alioth-binarytrees.gcc-7.c -lm 0.21u 0.00s 0.03r
	gcc -m64 -O3 -fopenmp -I/usr/include/apr-1 -lapr-1 -lgomp alioth-binarytrees.gcc-7.c -lm   0.21u 0.00s 0.03r
	gcc -m64 -O2 -fopenmp -I/usr/include/apr-1 -lapr-1 -lgomp alioth-binarytrees.gcc-7.c -lm   0.23u 0.00s 0.03r
	gc alioth-binarytrees   2.16u 0.04s 0.42r
	gc_B alioth-binarytrees 2.20u 0.04s 0.42r
	gcc -m64 -O3 binary-tree.c -lm  0.34u 0.00s 0.34r
	gcc -m64 -O2 binary-tree.c -lm  0.31u 0.00s 0.31r
	gc binary-tree  1.07u 0.00s 1.07r
	gc binary-tree-freelist 0.15u 0.00s 0.15r

regex-dna 100000
	gc alioth-regexdna      2.07u 0.00s 0.64r
	gc_B alioth-regexdna    2.22u 0.00s 0.71r
	gcc -m64 -O2 regex-dna.c -lpcre 0.25u 0.00s 0.26r
	gc regex-dna    1.63u 0.00s 1.64r
	gc regex-dna-parallel   1.84u 0.00s 0.72r
	gc_B regex-dna  1.63u 0.00s 1.64r

分析测试的数据, 有以下几个特征(仅针对当前的测试):

  • gcc-O3-O2以及-fomit-frame-pointer等优化参数对性能的优化在20%以内, 可以暂时忽略
  • gc_Bgc的对性能的优化在5%以内, 可以暂时忽略
  • BenchmarksGame 和 GoBench 的C版本测试程序性能很接近(fasta是BenchmarksGame稍好, binary-tree是GoBench稍好)
  • 大部分BenchmarksGame 和 GoBench 的Go版本测试程序性能差距巨大, GoBench要比BenchmarksGame快2~4X.
  • BenchmarksGame 的 spectralnorm 测试性能比 GoBench 的要好(6.75u/9.86u)
  • 经过我手工优化过的 GoBench 的 chai2010-spectral-norm 测试性能比 BenchmarksGame 的要好(5.15/6.75u)
  • BenchmarksGame 的 regexdna 暂时缺少C语言版本的测试数据(没有编译过)
  • GoBench 的 binary-tree-freelist 使用内存池对性能提高约 7X.

综上可以发现 BenchmarksGame 的很多 Go 版本测试程序性能较差(甚至快到10X的差距). 关于 BenchmarksGame 的 Go 测试程序性能低的原因, 大家可以自己去分析代码.

关于regex的测试主要是因为Go的regex标准库比高度优化的C库pcre还是较慢, 目前Go的regex库还有待进一步的优化.

关于pidigits的测试, BenchmarksGame 和 GoBench 基本是一致的: 目前math/biggmp的性能还有2倍的差距.

关于BenchmarksGame和GoBench 的测试差异的很多细节还需要进一步分析. 重点应该是64位系统下多核和并发的性能对比(毕竟Go是多核时代的编程语言).

官方的测试结论

http://go.googlecode.com/hg/test/bench/shootout/timing.log:

# Sep 26, 2012
# 64-bit ints, plus significantly better floating-point code.
# Interesting details:
# 	Generally something in the 0-10% slower range, some (binary tree) more
#	Floating-point noticeably faster:
#		nbody -25%
#		mandelbrot -37% relative to Go 1.
#	Other:
#		regex-dna +47%

Go已经和C差距在10%以内, 有特殊场景性能甚至更好.

2013.11.26 补充的官方数据:

# May 23, 2013
# Go 1.1, which includes precise GC, new scheduler, faster maps.
# 20%-ish speedups across many benchmarks.
# gccgo showing significant improvement (even though it's not yet up to Go 1.1)
#
# Standouts:
#	fannkuch, regex-dna, k-nucleotide, threadring, chameneos

在很多测试中, gccgo的性能已经开始超越gc编译的程序的性能.

大数运算的性能比 gmp 还在差 30~40%.

正则比pcre还慢约 5 倍.


https://chai2010.cn/

© 著作权归作者所有

chai2010

chai2010

粉丝 427
博文 102
码字总数 81536
作品 10
武汉
程序员
私信 提问
加载中

评论(120)

leaxoy
leaxoy

引用来自“chai2010”的评论

引用来自“Jack.arain”的评论

好吧, 硬要搞一段代码来展示一下这个问题, 也好. http://paste.ubuntu.org.cn/205771

链接中的代码, 存个档:
package main

import "fmt"

func main() {
var fn func();
var i = 10;
fn = func() {
fmt.Println(i);
}
i = 0;
fn();
}

// 显然上面变量i会受i=0;影响改变fn的输出. 但如果我想要的不是引用呢? 代码就该写成:


package main

import "fmt"

func main() {
var fn func();
var i = 10;
var c = i;
// 如果fn中使用的外部变量再多一点, 就会有N个多余的变量在这里声明, 这简直指定是要把代码变混乱.
// 并且你在使用c的时候, 你需要在脑海里记住它的所对应的变量是i, 也就是说得有一张map表在你的脑海里.
fn = func() {
fmt.Println(c);
}
i = 0;
fn();
}

// C++11中不存在这个问题, 完全不需要考虑这个问题.
这两段代码写的跟翔一样的感觉......
chai2010
chai2010 博主
新的 timing.sh 已经可以在 MinGW 运行,具体请参考:
http://code.google.com/p/go/source/detail?r=0997352b5359
francis-x
francis-x
个人感觉Go语言在超高并发下,还是有比较大的优势的。听说cloud foundry的负载均衡入口部分就是用Go实现的。什么场景决定使用什么语言,其它场景,感觉不到比Java有多少优势吧,个人观点。
刘兰琪
刘兰琪

引用来自“icosagon”的评论

引用来自“chai2010”的评论

引用来自“Jack.arain”的评论

好吧, 硬要搞一段代码来展示一下这个问题, 也好. http://paste.ubuntu.org.cn/205771

链接中的代码, 存个档:
package main

import "fmt"

func main() {
var fn func();
var i = 10;
fn = func() {
fmt.Println(i);
}
i = 0;
fn();
}

// 显然上面变量i会受i=0;影响改变fn的输出. 但如果我想要的不是引用呢? 代码就该写成:


package main

import "fmt"

func main() {
var fn func();
var i = 10;
var c = i;
// 如果fn中使用的外部变量再多一点, 就会有N个多余的变量在这里声明, 这简直指定是要把代码变混乱.
// 并且你在使用c的时候, 你需要在脑海里记住它的所对应的变量是i, 也就是说得有一张map表在你的脑海里.
fn = func() {
fmt.Println(c);
}
i = 0;
fn();
}

// C++11中不存在这个问题, 完全不需要考虑这个问题.

要不就是语言设计者为了编译器容易写和编译速度快,搞出这种脑残设计,尼玛,多人合作大型项目中,这程序员是要多亮的钛合金狗眼才能防范这种脑残设计带来的bug

大神,你能去了解下闭包再来喷好不,虽然我知道golang的设计者Ken Thompson、Rob Pike、Brad Fitzpatrick、Robert Griesemer、Russ Cox、Ian Lance Taylor...等等都是脑残,但是大神你也不要乱喷撒,毕竟你是神啊!应该高唱神啊XXXX
KeepMoving
KeepMoving

引用来自“lethe555”的评论

跟语言有关系么?比的是编译器的能力吧?

+100 就是编译器的能力
chai2010
chai2010 博主
刚提交了一个 Benchmarks Game 中 spectral-norm 测试的优化版本.
采用了 2倍的 runtime.NumCPU(), 目前比 openmp 优化的 C 语言版本还慢1倍.

详细的测试数据:
http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=spectralnorm

Go #3 是之前的版本, 约 3.7X 的时间
Go #2 是我刚提交的版本, 约 2.1X 的时间

PS:
有人刚提交了一个cgo-pcre版本的 regex-dna, 从 26X 减少到 8X.
不过感觉比C的基于tcl的版本还是慢很多.
chai2010
chai2010 博主

引用来自“icosagon”的评论

引用来自“chai2010”的评论

引用来自“Jack.arain”的评论

好吧, 硬要搞一段代码来展示一下这个问题, 也好. http://paste.ubuntu.org.cn/205771

链接中的代码, 存个档:
package main

import "fmt"

func main() {
var fn func();
var i = 10;
fn = func() {
fmt.Println(i);
}
i = 0;
fn();
}

// 显然上面变量i会受i=0;影响改变fn的输出. 但如果我想要的不是引用呢? 代码就该写成:


package main

import "fmt"

func main() {
var fn func();
var i = 10;
var c = i;
// 如果fn中使用的外部变量再多一点, 就会有N个多余的变量在这里声明, 这简直指定是要把代码变混乱.
// 并且你在使用c的时候, 你需要在脑海里记住它的所对应的变量是i, 也就是说得有一张map表在你的脑海里.
fn = func() {
fmt.Println(c);
}
i = 0;
fn();
}

// C++11中不存在这个问题, 完全不需要考虑这个问题.

要不就是语言设计者为了编译器容易写和编译速度快,搞出这种脑残设计,尼玛,多人合作大型项目中,这程序员是要多亮的钛合金狗眼才能防范这种脑残设计带来的bug

这是原代码写的有问题. Go的处理方式是:
func main() {
i := 10
defer func(i int) {
fmt.Println(i)
}(i)
i = 0
}

不可否认, 这对新学Go没几天的人确实是个坑.
FAQ已经写的很清楚了:
http://golang.org/doc/faq#closures_and_goroutines

"要不就是语言设计者为了编译器容易写和编译速度快,搞出这种脑残设计",
新学没几天就不要随便瞎喷, 请问你用Go写过多大的程序?
chai2010
chai2010 博主

引用来自“icosagon”的评论

引用来自“chai2010”的评论

引用来自“Jack.arain”的评论

好吧, 硬要搞一段代码来展示一下这个问题, 也好. http://paste.ubuntu.org.cn/205771

链接中的代码, 存个档:
package main

import "fmt"

func main() {
var fn func();
var i = 10;
fn = func() {
fmt.Println(i);
}
i = 0;
fn();
}

// 显然上面变量i会受i=0;影响改变fn的输出. 但如果我想要的不是引用呢? 代码就该写成:


package main

import "fmt"

func main() {
var fn func();
var i = 10;
var c = i;
// 如果fn中使用的外部变量再多一点, 就会有N个多余的变量在这里声明, 这简直指定是要把代码变混乱.
// 并且你在使用c的时候, 你需要在脑海里记住它的所对应的变量是i, 也就是说得有一张map表在你的脑海里.
fn = func() {
fmt.Println(c);
}
i = 0;
fn();
}

// C++11中不存在这个问题, 完全不需要考虑这个问题.

没搞懂,go的内部定义函数是运行时定义的?怎么像动态语言一样,这难道不会天下大乱吗?

Go是静态语言! 但是支持匿名函数(闭包), 变量也是静态类型(和C++11的auto类似的语法).
i
icosagon

引用来自“chai2010”的评论

引用来自“Jack.arain”的评论

好吧, 硬要搞一段代码来展示一下这个问题, 也好. http://paste.ubuntu.org.cn/205771

链接中的代码, 存个档:
package main

import "fmt"

func main() {
var fn func();
var i = 10;
fn = func() {
fmt.Println(i);
}
i = 0;
fn();
}

// 显然上面变量i会受i=0;影响改变fn的输出. 但如果我想要的不是引用呢? 代码就该写成:


package main

import "fmt"

func main() {
var fn func();
var i = 10;
var c = i;
// 如果fn中使用的外部变量再多一点, 就会有N个多余的变量在这里声明, 这简直指定是要把代码变混乱.
// 并且你在使用c的时候, 你需要在脑海里记住它的所对应的变量是i, 也就是说得有一张map表在你的脑海里.
fn = func() {
fmt.Println(c);
}
i = 0;
fn();
}

// C++11中不存在这个问题, 完全不需要考虑这个问题.

要不就是语言设计者为了编译器容易写和编译速度快,搞出这种脑残设计,尼玛,多人合作大型项目中,这程序员是要多亮的钛合金狗眼才能防范这种脑残设计带来的bug
i
icosagon

引用来自“chai2010”的评论

引用来自“Jack.arain”的评论

好吧, 硬要搞一段代码来展示一下这个问题, 也好. http://paste.ubuntu.org.cn/205771

链接中的代码, 存个档:
package main

import "fmt"

func main() {
var fn func();
var i = 10;
fn = func() {
fmt.Println(i);
}
i = 0;
fn();
}

// 显然上面变量i会受i=0;影响改变fn的输出. 但如果我想要的不是引用呢? 代码就该写成:


package main

import "fmt"

func main() {
var fn func();
var i = 10;
var c = i;
// 如果fn中使用的外部变量再多一点, 就会有N个多余的变量在这里声明, 这简直指定是要把代码变混乱.
// 并且你在使用c的时候, 你需要在脑海里记住它的所对应的变量是i, 也就是说得有一张map表在你的脑海里.
fn = func() {
fmt.Println(c);
}
i = 0;
fn();
}

// C++11中不存在这个问题, 完全不需要考虑这个问题.

没搞懂,go的内部定义函数是运行时定义的?怎么像动态语言一样,这难道不会天下大乱吗?
系统级编程语言性能大PK的笑话-Go语言

喜欢和不喜欢Go语言的都喜欢拿性能PK说事. 流传比较广的是benchmarksgame的PK数据: http://benchmarksgame.alioth.debian.org/u64q/go.php 在 benchmarksgame测试中, Go语言的性能已经由之前...

chai2010
2013/08/06
6.9K
7
Go1.1新特性介绍(语言和库更完善/性能提高约30%)

前几天GCC4.8发布, 已经部分包含Go1.1特性, 详细介绍: http://gcc.gnu.org/gcc-4.8/changes.html#go 根据golang-nuts的消息, 4月第1周可能会进入Go1.1发布流程(就是下周).要修复的问题还剩2...

chai2010
2013/03/27
11.7K
35
一个已经解决了的问题

不要跟帖了。已经设置最佳答案。 讨论中我突然意识到不能跟程序员在继续讨论这问题了,我的问题是性能回答都是用户体验。出发点上就有差距。 况且都没测试,上来就说自己的感受。这种问题虽然...

Foou
2013/11/04
754
12
.net core百万设备连接服务和硬件需求测试

随着物联网的普及,服务应用将面对大量物联设备处理;.net core经历过大量的优化后在各个模块的处理性能都有着比较出色的提升,针对网络方向的处理模块也有着显著的提升。以下主要测试.net ...

泥水佬
05/06
51
0
DevOps报告发布:亚洲不及北美五分之一

  【IT168 资讯】DevOps已被证明是一套可帮助各种规模的企业改进软件发布周期,软件质量,安全性以及快速反馈产品开发能力的实践。在过去六年,超过27,000个关于DevOps调查的回应,提供了有...

it168网站
2017/06/08
0
0

没有更多内容

加载失败,请刷新页面

加载更多

parseint和isNaN用法

本文转载于:专业的前端网站➭parseint和isNaN用法 <!doctype html><html><head><meta charset="utf-8"><title>无标题文档</title></head><body><script> var a='12'; alert......

前端老手
38分钟前
7
0
Kylin 精确去重在用户行为分析中的妙用

作者:史少锋,Apache Kylin committer & PMC,2019/10/11 在上次文章《如何在 1 秒内做到大数据精准去重》中,我们介绍了 Apache Kylin 为什么要支持大数据集上的精确去重,以及基于 Bitmap...

ApacheKylin
49分钟前
5
0
学习记录(二) es6基本语法(rest参数,模板化,axios模块,拦截器)

日常学习记录 模块化:把一个大文件分成多个小文件,按照一定规范进行拼接 es5写法: 导出:module.exports = 数据 导入:require("路径") /路径未添加后缀名时 //默认添加.js //把路径作为文件名...

Pole丶逐
53分钟前
4
0
以程序员的角度怎么购买一台「性价比高的电视」

前俩天有小伙伴在我的文章下留言,说能否把 【国内电视机都介绍一下】,今天我已在TV端开发多年的程序员的角度。谈谈已程序员的角度如何购买一台性价比高的电视。 国内大的电视机品牌介绍 长...

我们都很努力着
56分钟前
4
0
PhotoShop 色调:理解直方图/RGB通道信息

一、直方图:图表的形式,展示图像像素分布的情况 1.平均值:表示平均亮度 2.标准偏差值:表示亮度值范围内的中间值 3.像素: 表示用于计算直方图的像素总数 4.色阶:显示指针下面的区域亮度...

东方墨天
今天
7
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部