Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
OpenHarmony
Third Party Openssl
提交
0bd8d6e2
T
Third Party Openssl
项目概览
OpenHarmony
/
Third Party Openssl
大约 1 年 前同步成功
通知
9
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看板
You need to sign in or sign up before continuing.
提交
0bd8d6e2
编写于
5月 10, 2007
作者:
A
Andy Polyakov
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Commentary updates to SHA for sparcv9.
上级
160065c5
变更
2
显示空白变更内容
内联
并排
Showing
2 changed file
with
19 addition
and
8 deletion
+19
-8
crypto/sha/asm/sha1-sparcv9.pl
crypto/sha/asm/sha1-sparcv9.pl
+9
-7
crypto/sha/asm/sha512-sparcv9.pl
crypto/sha/asm/sha512-sparcv9.pl
+10
-1
未找到文件。
crypto/sha/asm/sha1-sparcv9.pl
浏览文件 @
0bd8d6e2
...
...
@@ -8,13 +8,15 @@
# ====================================================================
# Performance improvement is not really impressive on pre-T1 CPU: +8%
# over Sun C and +25% over gcc [3.3]. While on T1, ... And there
# is a gimmick. X[16] vector is packed to 8 64-bit registers and as
# result nothing is spilled on stack. In addition input data is loaded
# in compact instruction sequence, thus minimizing the window when the
# code is subject to [inter-thread] cache-thrashing hazard. The goal
# is to ensure scalability on UltraSPARC T1, or rather to avoid decay
# when amount of active threads exceeds the number of physical cores.
# over Sun C and +25% over gcc [3.3]. While on T1, a.k.a. Niagara, it
# turned to be 40% faster than 64-bit code generated by Sun C 5.8 and
# >2x than 64-bit code generated by gcc 3.4. And there is a gimmick.
# X[16] vector is packed to 8 64-bit registers and as result nothing
# is spilled on stack. In addition input data is loaded in compact
# instruction sequence, thus minimizing the window when the code is
# subject to [inter-thread] cache-thrashing hazard. The goal is to
# ensure scalability on UltraSPARC T1, or rather to avoid decay when
# amount of active threads exceeds the number of physical cores.
$bits
=
32
;
for
(
@ARGV
)
{
$bits
=
64
if
(
/\-m64/
||
/\-xarch\=v9/
);
}
...
...
crypto/sha/asm/sha512-sparcv9.pl
浏览文件 @
0bd8d6e2
...
...
@@ -23,7 +23,16 @@
#
# SHA512 on UltraSPARC T1.
#
# ...
# 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
# loads to access X[16], which I consciously traded for 32-/64-bit ABI
# duality [as per above]. But it surpasses 32-bit Sun C generated code
# by 60%, not to mention that it doesn't suffer from severe decay when
# running 4 times physical cores threads and that it leaves gcc [3.4]
# behind by over 4x factor! If compared to SHA256, single thread
# performance is only 10% better, but overall throughput for maximum
# amount of threads for given CPU exceeds corresponding one of SHA256
# by 30% [again, optimal coefficient is 50%].
$bits
=
32
;
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.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录