cmu

烧脑!CMU、北大等合著论文真的找到了神经网络的全局最优解

笑着哭i 提交于 2019-12-27 07:16:50
烧脑!CMU、北大等合著论文真的找到了神经网络的全局最优解 机器之心 ​ 已认证的官方帐号 811 人赞同了该文章 选自arXiv,作者:Simon S. Du、Jason D. Lee、Haochuan Li、Liwei Wang、Xiyu Zhai,机器之心编译,参与:思源、王淑婷、张倩。 一直以来,我们都不知道为什么深度神经网络的损失能降到零,降到零不代表着全局最优了么?这不是和一般 SGD 找到的都是局部极小点相矛盾么?最近 CMU、北大和 MIT 的研究者分析了深层全连接网络和残差网络,并表示使用梯度下降训练过参数化的深度神经网络真的能找到全局最优解。 用一阶方法训练的神经网络已经对很多应用产生了显著影响,但其理论特性却依然是个谜。一个经验观察是,即使优化目标函数是非凸和非平滑的,随机初始化的一阶方法(如随机梯度下降)仍然可以找到全局最小值(训练损失接近为零),这是训练中的第一个神秘现象。令人惊讶的是,这个特性与标签无关。在 Zhang 等人的论文 [2016] 中,作者用随机生成的标签取代了真正的标签,但仍发现随机初始化的一阶方法总能达到零训练损失。 人们普遍认为过参数化是导致该现象的主要原因,因为神经网络只有具备足够大的容量时才能拟合所有训练数据。实际上,很多神经网络架构都高度过参数化。例如,宽残差网络(Wide Residual Network)的参数量是训练数据的

CMU Database Systems - Distributed OLTP DB

♀尐吖头ヾ 提交于 2019-11-28 01:06:23
scale-up和scale-out scale-up会有上限,无法不断up,而且相对而言,up升级会比较麻烦,所以大数据,云计算需要scale-out scale-out,就是分布式数据库,刚开始肯定是Shared Nothing,但是分布式也引入了更高的架构复杂度和维护成本 所以现在的趋势,是架构分层,层之间是逻辑的scale-up,层内部是物理的scale-out 最终sharing-everything,其实在架构上又回到了scale-up 所以随着硬件的进步和技术的演进,架构上没有绝对的好坏 Shared Nothing是最常见的,也是最开始的分布式方案 共享磁盘,代表是Amazon的Aurora 执行层和存储层分离,那么当前在数据库层就不需要管副本同步的问题,主挂了,备拉起看到的数据还是一样的,在数据库层只有一份磁盘数据 共享内存,共享磁盘虽然解决大部分数据同步的问题,但是执行层仍然是有状态的,因为内存中的状态,并没有落盘,所以failover后仍然需要状态恢复 如果共享内存,那么执行层就可以完全无状态,那样维护成本会大幅降低 但是很明显,共享内存很难实现,稳定性和性能的要求会很高,现在没有数据库实现共享内存 早期的分布式数据库, 分布式数据库设计需要考虑一些架构上的问题, 同构还是异构,Mongo是典型的异构架构 数据Partition,既然是分布式数据库

FreeSWITCH安装解决mod_flite-install安装问题

[亡魂溺海] 提交于 2019-11-27 21:25:35
FreeSWITCH源码安装目录执行mod_flite-install,提示you must install libflite-dev tu build mod_flite 首先编辑/usr/local/src/freeswitch/module.conf,注释掉:asr_tts/mod_flite 此问题为主要是系统已经安装了flite-1.3的版本,需要手动卸载此版本 yum remove -y lite 下载flite-2.1.0版本 git clone https://github.com/festvox/flite.git flite-2.1.0 cd flite-2.1.0 ./configure --prefix=/usr/lib64/flite2.1 --enable-shared #注意一定要加上enable-shared,否则编译不出来动态链接库,后面编译还是会失败. 2.0.0版还要 --enable-fPIC make && make install ln -s /usr/lib64/flite2.1/lib/* /usr/lib64/ vi /usr/lib64/pkgconfig/flite.pc 粘贴以下配置 prefix=/usr/lib64/flite2.1 exec_prefix=${prefix} libdir=${exec_prefix}

分布式系统权限校验

穿精又带淫゛_ 提交于 2019-11-27 01:31:25
1、场景:有一个中心服务器cmu,多种业务服务器(比如dmu,vtdu),每种业务服务器有一组服务,这种服务一主多从,具备主从切换和负载均衡的功能。客户端首先去连接中心服务器,需要鉴权,客户端sdk负责去连接业务服务器。连接业务服务器都能连接成功。那么问题来了。 2、恶意软件绕过cmu,直接去连接dmu,发送控制命令,怎么办? 3、解决办法,客户端登陆cmu,cmu根据用户名密码鉴权,成功返回一个令牌,客户端向dmu发送命令的时候,带着令牌,dmu向cmu查询令牌是否有效,已经对应的userId。如果客户端绕过cmu,直接向dmu发送命令(带着一个无效的令牌),dmu向cmu检查令牌的时候,cmu返回无效的令牌。 转载于:https://www.cnblogs.com/nzbbody/p/4438636.html 来源: https://blog.csdn.net/weixin_30642869/article/details/99234271