Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
OpenHarmony
Third Party Openssl
提交
79fe664f
T
Third Party Openssl
项目概览
OpenHarmony
/
Third Party Openssl
1 年多 前同步成功
通知
10
Star
18
Fork
1
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
T
Third Party Openssl
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
提交
79fe664f
编写于
9月 26, 2007
作者:
A
Andy Polyakov
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Clarify commentary in sha512-sparcv9.pl.
上级
5f0477f4
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
14 addition
and
6 deletion
+14
-6
crypto/sha/asm/sha512-sparcv9.pl
crypto/sha/asm/sha512-sparcv9.pl
+14
-6
未找到文件。
crypto/sha/asm/sha512-sparcv9.pl
浏览文件 @
79fe664f
...
@@ -17,7 +17,7 @@
...
@@ -17,7 +17,7 @@
# Performance is >75% better than 64-bit code generated by Sun C and
# Performance is >75% better than 64-bit code generated by Sun C and
# over 2x than 32-bit code. X[16] resides on stack, but access to it
# over 2x than 32-bit code. X[16] resides on stack, but access to it
# is scheduled for L2 latency and staged through 32 least significant
# is scheduled for L2 latency and staged through 32 least significant
# bits of %l0-%l7. The latter is done to achieve 32-/64-bit
bit
ABI
# bits of %l0-%l7. The latter is done to achieve 32-/64-bit ABI
# duality. Nevetheless it's ~40% faster than SHA256, which is pretty
# duality. Nevetheless it's ~40% faster than SHA256, which is pretty
# good [optimal coefficient is 50%].
# good [optimal coefficient is 50%].
#
#
...
@@ -25,14 +25,22 @@
...
@@ -25,14 +25,22 @@
#
#
# It's not any faster than 64-bit code generated by Sun C 5.8. This is
# It's not any faster than 64-bit code generated by Sun C 5.8. This is
# because 64-bit code generator has the advantage of using 64-bit
# because 64-bit code generator has the advantage of using 64-bit
# loads
to access X[16], which I consciously traded for 32-/64-bit ABI
# loads
(*) to access X[16], which I consciously traded for 32-/64-bit
#
duality [as per above]. But it surpasses 32-bit Sun C generated code
#
ABI duality [as per above]. But it surpasses 32-bit Sun C generated
#
by 60%, not to mention that it doesn't suffer from severe decay when
#
code by 60%, not to mention that it doesn't suffer from severe decay
#
running 4 times physical cores threads and that it leaves gcc [3.4]
#
when running 4 times physical cores threads and that it leaves gcc
# behind by over 4x factor! If compared to SHA256, single thread
#
[3.4]
behind by over 4x factor! If compared to SHA256, single thread
# performance is only 10% better, but overall throughput for maximum
# performance is only 10% better, but overall throughput for maximum
# amount of threads for given CPU exceeds corresponding one of SHA256
# amount of threads for given CPU exceeds corresponding one of SHA256
# by 30% [again, optimal coefficient is 50%].
# by 30% [again, optimal coefficient is 50%].
#
# (*) Unlike pre-T1 UltraSPARC loads on T1 are executed strictly
# in-order, i.e. load instruction has to complete prior next
# instruction in given thread is executed, even if the latter is
# not dependent on load result! This means that on T1 two 32-bit
# loads are always slower than one 64-bit load. Once again this
# is unlike pre-T1 UltraSPARC, where, if scheduled appropriately,
# 2x32-bit loads can be as fast as 1x64-bit ones.
$bits
=
32
;
$bits
=
32
;
for
(
@ARGV
)
{
$bits
=
64
if
(
/\-m64/
||
/\-xarch\=v9/
);
}
for
(
@ARGV
)
{
$bits
=
64
if
(
/\-m64/
||
/\-xarch\=v9/
);
}
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录