[image]30 已知BUF1中有N1个按从小到大的顺序排列互不相等的字符号数，BUF2中有N2_百度知道
[image]30 已知BUF1中有N1个按从小到大的顺序排列互不相等的字符号数，BUF2中有N2
[image]30 已知BUF1中有N1个按从小到大的顺序排列互不相等的字符号数，BUF2中有N2用汇编语言
我有更好的答案
下面还是举例来说明：去掉else后的问题在到底在哪里，为什么结果不对了。依旧a[0]=&12345&,a[1]=&12452&；
前两个相等故不做if。第三四个a[1]值大，此处就本应该结束循环不再比较了，但是由于去掉了else语句，故依旧执行循环。但因为条件不成立，而只是进行j++；当到第五个数字时，由于a[0]中为5，而a[1]中为2，故if的条件成了，所以a[0]和a[1]进行交换，但是这显然是错误的。因为a[1]的前4项中有比a[0]大的数，早就该结束循环不比较第五个数字了。原来大意了，呵呵，差点误导了你！实在是抱歉，现在解释的还可以吧？我仔细分析过了，应该没有任何的问题。附：
改进建议：既然你知道strcpy()函数，为什么还要用第三个for循环一个一个字符的比较呢？可以用strcmp()来进行直接比较，这样就去掉了第三个for语句。
改进代码如下，供参考：
#include &stdio.h&
#include &string.h&
void main(){
char b[20],a[5][20];
printf(&input:\n&);
for(i=0;i&5;i++)
gets(a[i]);
for(i=0;i&5;i++){
for(j=i+1;j&5;j++){
if(strcmp(a[i],a[j])&0){
strcpy(b,a[j]);
strcpy(a[j],a[i]);
strcpy(a[i],b);
printf(&\n\n排序后的结果为：\n\n&);
for(i=0;i&5;i++)
puts(a[i]);
这样是不是清楚点呢？几乎和一般的整数数组的排序一样了，不是吗？呵呵！strcmp的具体说明：
int strcmp(const char *string1,const dhar *string2);
按字典序比较字符串string1和string2，若string1排在string2前，返回值小于0；若string1和string2相等，返回值为0；若string1排在string2后，返回值大于0；
毅衣公司京东小二
为您推荐：
其他类似问题
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。用串操作指令实现将内存定义好的两个字节串BUF1和BUF2相加后，存放到另一个串BUF3中的功能。_百度知道
用串操作指令实现将内存定义好的两个字节串BUF1和BUF2相加后，存放到另一个串BUF3中的功能。
CX，COUNTMOV
SI，OFFSET BUF1MOV
DI，OFFSET BUF3MOV
BX，OFFSET BUF2AGAIN：LODSBADD
AL，[BX]STOSBINC
AGAIN哪位高手能解释下每步都是干嘛的谢谢
我有更好的答案
MOV CX，COUNT
cx存放count地址MOV SI，OFFSET BUF1
计算出BUF1地址存入SIMOV DI，OFFSET BUF3
计算出BUF2地址存入diMOV BX，OFFSET BUF2
计算出BUF3地址存入bxAGAIN：LODSB
是将 ds:[si] 处的字节送到 AL 中, si 将随 DF 的设置 '
增 1'(DF=0,使用 CLD 指令设置) 或者是 '减 1'(DF=1,
使用 STD 指令设置) 而指向下一个字节ADD AL，[BX]
将地址[BX]中的数值与al相加INC BX
bx加1DEC CX
计数器cx减1JNZ AGAIN
cx非0则循环跳转到标号AGAIN 处继续,如果cx为0则跳出循环
为您推荐：
其他类似问题
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。Netty 4.0 新的特性及需要注意的地方 - 技术翻译 - 开源中国社区
Netty 4.0 新的特性及需要注意的地方
【已翻译100%】
英文原文：
推荐于 5年前 (共 24 段, 翻译完成于 04-03)
参与翻译&(3人)&: ,
这篇文章和你一起过下Netty的主发行版本的一些显著的改变和新特性，让你在把你的应用程序转换到新版本的时候有个概念。
项目结构改变
Netty的包名从org.jboss.netty改为io.netty，因为。
二进制JAR包被分为了多个子模块以便用户能够从类路径中去掉非必需的特性。当前的结构如下：
project parent
utility and logging
buffer API
channel API and its core implementations
RTRX transport implementation
SCTP transport implementation
UDT transport implementation
channel handlers
codec framework
HTTP, Web Sockets, SPDY, and RTSP codec
Socks codec
generates an all-in-one JAR
generates a tarball distribution
所有的Netty的Jar（除了netty-all外）包现在都是OSGI的bundle，能够用在你喜欢的OSGI容器上。
常用API的变化
现在Netty里的大部分操作都支持简洁的方法链。
不能配置的getter现在都没有了get/is前缀 （如Channel.getRemoteAddress()→Channel.remoteAddress()）
&翻译得不错哦！
Buffer API变化
ChannelBuffer → ByteBuf
由于上文所提到的结构上的变化，buffer API现在可以作为一个单独的包被使用。为此，ChannelBuffer这个类型名也不那么讲得通了，而应该变更为ByteBuf。
用来创建新buffer的功能类ChannelBuffers被拆分为两个功能类：Unpooled和BufUtil。就像这个名字所暗示的，4.0引入了一个新的池化的ByteBufs，它可以通过ByteBuf的分配器（Allocator）的对应实现ByteBufAllocator来获得。
大多数的buffer变成了动态的，具备可配置的最大容量
在3.x时期，buffer分为固定和动态两种类型。一个固定buffer的容量在创建之后就无法改变，而动态buffer的容量在write*（译者按：writeByte,writeInt,writeLong...）方法需要更多空间时自动扩容。
从4.0开始，所有buffer都变成了动态的。但是，相对于之前的动态进行了优化。你可以更容易也更安全的对一个buffer的容量进行扩大和缩小。之所以说它容易是因为有一个新的ByteBuf.capacity(int newCapacity)的方法。说它安全是因为你可以设置一个容量的最大值，以防止容量没有限制的增大。
// 不要再使用 dynamicBuffer() - 使用 buffer().
ByteBuf buf = ByteBuf.buffer();
// 增加buffer的容量
buf.capacity(1024);
// 缩减buffer的容量 (最后的512个byte被丢弃)
buf.capacity(512);
唯一的例外是那些使用wrappedBuffer方法创建的，包装(warp)了一个buffer或一个byte数组的buffer。你无法扩大它的容量，因为这样会使包装一个已有buffer的目的是去意义——减少内存的复制。如果你想要在包装了一个buffer之后改变它的容量，你应该重新创建一个拥有足够容量的buffer，然后将你想要包装的那个buffer的内容复制过来。
&翻译得不错哦！
新接口: CompositeByteBuf
一个新的名叫CompositeByteBuf的接口为组合buffer(composite buffer)的实现定义了多种高级的操作。一个用户可以使用组合buffer，以只比随机访问大一点的代价达到一个批量内存复制的目的。要创建一个新的组合buffer，可以像以前一样使用Unpooled.wrappedBuffer(... 译者注：此处省略号应该是指省略方法参数，下同)或Unpooled.compositeBuffer(...)。
可预知的NIO buffer转型
在3.x中，ChannelBuffer.toByteBuffer()以及它的其他变体所提供的约定并不那么明确。用户无法确定这些方法会返回一个拥有共享数据的视图buffer还是一个拥有独立数据的通过复制得到的buffer。4.0将toByteBuffer()替换为ByteBuf.nioBufferCount()，nioBuffer()，以及nioBUffers()。如果调用nioBufferCount()返回0，用户总是可以通过调用copy().nioBuffer()来获得一个复制的buffer。
对小字节序变更的支持
对小字节序的支持经历了重大变化。在之前的版本中，一个用户为了得到一个小字节序的buffer有两种选择：特别指定一个LittleEndianHeapChannelBufferFactory；用目标字节序将已存在的buffer包装起来。4.0添加了一个新方法，ByteBuf.order(ByteOrder)。这个方法返回当前buffer对象的一个具有指定字节序的视图buffer：
import io.netty.buffer.ByteB
import io.netty.buffer.U
import java.nio.ByteO
ByteBuf buf = Unpooled.buffer(4);
buf.setInt(0, 1);
// 打印出 ''
System.out.format("%08x%n", buf.getInt(0));
ByteBuf leBuf = buf.order(ByteOrder.LITTLE_ENDIAN);
// 打印出 ''
System.out.format("%08x%n", leBuf.getInt(0));
assert buf != leB
assert buf == buf.order(ByteOrder.BIG_ENDIAN);
&翻译得不错哦！
Pooled ByteBuf
前面已经提到Netty引入了pooledByteBufinstances。这在很多方面都很实用，举列如下：
限制了GC压力，这是因为使用unpooled ByteBufs会造成沉重的分配与再分配问题
Better handling of direct (native)ByteBuf更好的处理直接（本地）的ByteBuf
一个ByteBuf 可以被一个ByteBufAllocator包含.
public interface ByteBufAllocator {
ByteBuf buffer();
ByteBuf buffer(int initialCapacity);
ByteBuf buffer(int initialCapacity, int maxCapacity);
ByteBuf heapBuffer();
ByteBuf heapBuffer(int initialCapacity);
ByteBuf heapBuffer(int initialCapacity, int maxCapacity);
ByteBuf directBuffer();
ByteBuf directBuffer(int initialCapacity);
ByteBuf directBuffer(int initialCapacity, int maxCapacity);
ByteBuf ioBuffer();
CompositeByteBuf compositeBuffer();
CompositeByteBuf compositeBuffer(int maxNumComponents);
CompositeByteBuf compositeHeapBuffer();
CompositeByteBuf compositeHeapBuffer(int maxNumComponents);
CompositeByteBuf compositeDirectBuffer();
CompositeByteBuf compositeDirectBuffer(int maxNumComponents);
} 要想从一个handler那里获取当前的
ByteBufAllocator,可以使用ChannelHandlerContext.alloc()或Channel.alloc()方法:
Channel channel = ...;
ByteBuf buf = channel.alloc().buffer(512);
channel.write(buf);
ChannelHandlerContext ctx = ...
ByteBuf buf2 = ctx.alloc().buffer(512);
channel.write(buf2)
一旦一个ByteBuf被写入远程节点，它会再次自动的释放进入释放到池（the pool）里。
默认的ByteBufAllocator为PooledByteBufAllocator.如果你不希望使用buffer pooling或使用你自己的allocator，你可以运用Channel.config().setAllocator(..)，以及一个可供选择的&allocator，比如UnpooledByteBufAllocator。
&翻译得不错哦！
Channel API的变化
在4.0中，许多io.netty.channel包中的类都经历大量修改，因此文本上的简单搜索-替换是无法让你基于3.x的程序迁移到4.0上。这个部分会尝试将这些重大变更背后的思考过程展示出来，而不只是简单地作为展示所有变更。
翻新后的ChannelHandler接口
Upstream → Inbound, Downstream → Outbound
对于初学者来说，术语'upstream'（译者注：直译为向上游，有点像TCP/IP协议栈中从下往上，从物理层最终到达应用层这么一个流程）和'downstream'有点让人迷惑。在4.0中，只要可能，都会使用'inbound'（译者注：直译为开往内地的，相对于upstream确实更贴切，即指数据从外部网络经历层层filter到达我们的处理逻辑）和'outbound'来替换他们。
新的ChannelHandler继承层次
在3.x时代，ChannelHandler只是一个标记接口，而在ChannelUpstreamHandler、ChannelDownstreamHandler、LifeCycleAwareChannelHandler定义了具体的处理器方法。在Netty 4中，ChannelHandler将LifeCycleAwareChannelHandler接口和一堆实现辅助方法融合到了一起，具体见代码：
public interface ChannelHandler {
void beforeAdd(ChannelHandlerContext ctx) throws E
void afterAdd(ChannelHandlerContext ctx) throws E
void beforeRemove(ChannelHandlerContext ctx) throws E
void afterRemove(ChannelHandlerContext ctx) throws E
void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws E
void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws E
下方的图表描述了这个新的类型集成层次：
fixme（原文中还没有插入此图）
&翻译得不错哦！
事件对象从ChannelHandler中消失了
在3.x时代，所有的I/O操作都会创建一个新的ChannelEvent对象。对每个读或写的操作，还会额外创建一个新的ChannelBuffer对象。由于将资源管理和buffer的池化交给了JVM，这实际上极大地简化了Netty的内部实现。但是，基于Netty开发的应用在高负载下运行时，有时会观察到GC（Garbage Collection）的压力增大或变化不定，这些问题的根源也来自于这里。
4.0通过把事件对象替换为直接与类型相对应（译者注：原文为strongly typed，但是我觉得直译为强类型不太容易理解）的方法调用，几乎完全避免了事件对象的创建。3.x中，有类似于handleUpstream()和handleDownstream()这种能够捕获所有相关类型事件的处理器方法，4.0中你将不会再看到它们的身影了。所有的事件类型现在都有各自对应的处理器方法：
// 3.x时代:
void handleUpstream(ChannelHandlerContext ctx, ChannelEvent e) throws E
void handleDownstream(ChannelHandlerContext ctx, ChannelEvent e) throws E
void channelRegistered(ChannelHandlerContext ctx) throws E
void channelUnregistered(ChannelHandlerContext ctx) throws E
void channelActive(ChannelHandlerContext ctx) throws E
void channelInactive(ChannelHandlerContext ctx) throws E
void inboundBufferUpdated(ChannelHandlerContext ctx) throws E
void bind(ChannelHandlerContext ctx, SocketAddress localAddress, ChannelFuture future) throws E
void connect(
ChannelHandlerContext ctx, SocketAddress remoteAddress,
SocketAddress localAddress, ChannelFuture future) throws E
void disconnect(ChannelHandlerContext ctx, ChannelFuture future) throws E
void close(ChannelHandlerContext ctx, ChannelFuture future) throws E
void deregister(ChannelHandlerContext ctx, ChannelFuture future) throws E
void flush(ChannelHandlerContext ctx, ChannelFuture future) throws E
void read(ChannelHandlerContext ctx);
void sendFile(ChannelHandlerContext ctx, FileRegion region, ChannelPromise promise) throws E
ChannelHandlerContext类也被修改来反映上述提到的变化:
// Before:
ctx.sendUpstream(evt);
ctx.fireInboundBufferUpdated();
所有这些变化意味着用户无法去扩展ChannelEvent这个已经不存在的接口了。那用户要怎样才能定义他或她自己的事件类型呢，就像IdleStateEvent？4.0中的ChannelHandler有一个处理器方法叫做userEventTriggered()，它就是被设计用来满足这种特殊的用户需求。
&翻译得不错哦！
Simplified channel state model
在3.x中，当一个新的Channel被创建并连接成功，至少三个ChannelStateEvent会被触发：channelOpen、channelBound以及channelConnected。当一个Channel关闭，则对应channelDisconnected、channelUnbound以及channelClosed三个事件。
但是，触发这么多事件的意义并不那么明显。如果在一个Channel进入可读或可写的状态时通知用户，想来会更有帮助。
channelOpen、channelBound和channelConnected被合并为channelActive。channelDisconnected、channelUnbound和channelClosed被合并为channelInactive。类似的，Channel.isBound()和Channel.isConnected()也被合并为了Channel.isActive()。
需要注意的是，channelRegistered和channelUnregistered这两个事件与channelOpen和channelClosed具有的意义是不一样的。它们（channelRegistered和channelUnregistered）是在支持Channel的动态注册、注销以及再注册时被引入的，就像下图所示：
&翻译得不错哦！
每个处理器的缓存
不像3.x那样在每次读操作都简历一个新堆里的缓存来触发上游的MessageEvent，4.0不会每次都创建新的 缓存。它直接从socket中读取数据到由用户的ChannelInboundByteHandler和ChannelInboundMessageHandler实现创建的入站缓存。
因为由上述处理器创建的入站缓存直到关联的通道关闭前都会重用，所以在上面的GC和内存带宽消耗都能保持较小。同样，当接收到的数据被销毁时用户已经完成操作，codec的实现就变得更简单和有效了。
&翻译得不错哦！
在创建出站缓存时也是差不多的（不会新建）。用户的ChannelOutBoundBYteHandler和ChannelOutboundMessageHandler来操作。
不需要每条消息都有一个事件
4.0里不再有了messageReceived或writeRequested处理器方法。它们被inboundBufferUpdated和flush代替了。用户的入队一个或多个消息到一个入站（或出站）缓存同时会出发一个inboundBUfferUpdated（或flush）事件。
public void inboundBufferUpdated(ChannelHandlerContext ctx) {
Queue&MyMessage& in = ctx.inboundMessageBuffer();
Queue&MyNewMessage& out = ctx.nextInboundMessageBuffer();
for (;;) {
MyMessage m = in.poll();
if (m == null) {
MyNewMessage decoded = decode(m);
out.add(decoded);
ctx.fireInboundBufferUpdated();
public void flush(ChannelHandlerContext ctx, ChannelFuture future) {
Queue&MyNewMessage& in = ctx.outboundMessageBuffer();
Queue&MyMessage& out = ctx.nextOutboundMessageBuffer();
for (;;) {
MyNewMessage m = in.poll();
if (m == null) {
MyMessage encoded = encode(m);
out.add(encoded);
ctx.flush(future);
} 作为选择，用户能够在每个单独的入站（或出站）消息中触发这样的事件来模拟老的行为，尽管相对新方法来说效率更低。
&翻译得不错哦！
消息处理器 vs. 字节处理器
在3.x里一个MessageEvent持有一个任意的对象。它能够是一个ChannelBuffer或是一个用户自定义的对象，它们都是同样对待的：
public void messageReceived(ChannelHandlerContext ctx, MessageEvent evt) {
Object msg = evt.getMessage();
if (msg instanceof ChannelBuffer) {
ChannelBuffer buf = (ChannelBuffer)
MyMessage myMsg = (MyMessage)
} 在4.0里，它们就分别对待了，因为一个处理器不再处理一个独立的消息，而是处理多种多样的消息：
public void inboundBufferUpdated(ChannelHandlerContext ctx) {
if (ctx.hasInboundByteBuffer()) {
ByteBuf buf = ctx.inboundByteBuffer();
Queue&MyMessage& buf = ctx.inboundMessageBuffer();
for (;;) {
MyMessage msg = buf.poll();
if (buf == null) {
} 你可能发现一个ServerChannel的处理器是一个入站缓存是Queue&Channel&的入站处理器是较为有趣的。
处理器适配器
大多数用户都发现创建和管理它的生命周期是繁琐的，因此它支持用户扩展预定义好的适配器类来使得更方便：
ChannelHandlerAdapter
ChannelStateHandlerAdapter
ChannelOperationHandlerAdapter
ChannelInboundMessageHandlerAdapter
ChannelInboundByteHandlerAdapter
ChannelOutboundMessageHandlerAdapter
ChannelOutboundByteHandlerAdapter
&翻译得不错哦！
我们的翻译工作遵照 ，如果我们的工作有侵犯到您的权益，请及时联系我们
Thank you, 已更正
看的比较吃力啊
之前经常翻译啊 最近好懒。。
之前经常翻译啊 最近好懒。。哦，也许是你累了。累了就少写点代码，多看看这种文档，多看几次 翻译的时候就顺了极客学院团队出品 · 更新于
下载与安装
你可以使用我们提供的 Pip, Docker, Virtualenv, Anaconda 或 源码编译的方法安装 TensorFlow.
是一个 Python 的软件包安装与管理工具.
在安装 TensorFlow 过程中要涉及安装或升级的包详见
首先安装 pip (或 Python3 的 pip3 ):
# Ubuntu/Linux 64-bit
$ sudo apt-get install python-pip python-dev
# Mac OS X
$ sudo easy_install pip
安装 TensorFlow :
# Ubuntu/Linux 64-bit, CPU only, Python 2.7:
$ sudo pip install --upgrade https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-0.8.0-cp27-none-linux_x86_64.whl
# Ubuntu/Linux 64-bit, GPU enabled, Python 2.7. Requires CUDA toolkit 7.5 and CuDNN v4.
# For other versions, see "Install from sources" below.
$ sudo pip install --upgrade https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow-0.8.0-cp27-none-linux_x86_64.whl
# Mac OS X, CPU only:
$ sudo easy_install --upgrade six
$ sudo pip install --upgrade https://storage.googleapis.com/tensorflow/mac/tensorflow-0.8.0-py2-none-any.whl
如果是 Python3 :
# Ubuntu/Linux 64-bit, CPU only, Python 3.4:
$ sudo pip3 install --upgrade https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-0.8.0-cp34-cp34m-linux_x86_64.whl
# Ubuntu/Linux 64-bit, GPU enabled, Python 3.4. Requires CUDA toolkit 7.5 and CuDNN v4.
# For other versions, see "Install from sources" below.
$ sudo pip3 install --upgrade https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow-0.8.0-cp34-cp34m-linux_x86_64.whl
# Mac OS X, CPU only:
$ sudo easy_install --upgrade six
$ sudo pip3 install --upgrade https://storage.googleapis.com/tensorflow/mac/tensorflow-0.8.0-py3-none-any.whl
备注：如果之前安装过 TensorFlow & 0.7.1 的版本,应该先使用 pip uninstall 卸载 TensorFlow 和 protobuf ,保证获取的是一个最新 protobuf 依赖下的安装包.
之后可以一下.
基于 Docker 的安装
我们也支持通过
运行 TensorFlow.
该方式的优点是不用操心软件依赖问题.
首先, . 一旦 Docker
已经启动运行, 可以通过命令启动一个容器:
$ docker run -it b.gcr.io/tensorflow/tensorflow
该命令将启动一个已经安装好 TensorFlow 及相关依赖的容器.
默认的 Docker 镜像只包含启动和运行 TensorFlow 所需依赖库的一个最小集. 我们额外提供了
下面的容器, 该容器同样可以通过上述 docker run 命令安装:
b.gcr.io/tensorflow/tensorflow-full: 镜像中的 TensorFlow 是从源代码完整安装的,
包含了编译和运行 TensorFlow 所需的全部工具. 在该镜像上, 可以直接使用源代码进行实验,
而不需要再安装上述的任何依赖.
基于 VirtualEnv 的安装
我们推荐使用
创建一个隔离的容器, 来安装 TensorFlow. 这是可选的, 但是这样做能使排查安装问题变得更容易.
首先, 安装所有必备工具:
# 在 Linux 上:
$ sudo apt-get install python-pip python-dev python-virtualenv
# 在 Mac 上:
$ sudo easy_install pip
# 如果还没有安装 pip
$ sudo pip install --upgrade virtualenv
接下来, 建立一个全新的 virtualenv 环境. 为了将环境建在 ~/tensorflow
目录下, 执行:
$ virtualenv --system-site-packages ~/tensorflow
$ cd ~/tensorflow
然后, 激活 virtualenv:
$ source bin/activate
# 如果使用 bash
$ source bin/activate.csh
# 如果使用 csh
(tensorflow)$
# 终端提示符应该发生变化
在 virtualenv 内, 安装 TensorFlow:
(tensorflow)$ pip install --upgrade &$url_to_binary.whl&
接下来, 使用类似命令运行 TensorFlow 程序:
(tensorflow)$ cd tensorflow/models/image/mnist
(tensorflow)$ python convolutional.py
# 当使用完 TensorFlow
(tensorflow)$ deactivate
# 停用 virtualenv
# 你的命令提示符会恢复原样
基于 Anaconda 的安装
是一个集成许多第三方科学计算库的 Python 科学计算环境,Anaconda 使用 conda 作为自己的包管理工具,同时具有自己的,类似 Virtualenv.
和 Virtualenv 一样,不同 Python 工程需要的依赖包,conda 将他们存储在不同的地方。 TensorFlow 上安装的 Anaconda 不会对之前安装的 Python 包进行覆盖.
安装 Anaconda
建立一个 conda 计算环境
激活环境,使用 conda 安装 TensorFlow
安装成功后,每次使用 TensorFlow 的时候需要激活 conda 环境
安装 Anaconda :
参考 Anaconda 的下载页面的
建立一个 conda 计算环境名字叫tensorflow:
# Python 2.7
$ conda create -n tensorflow python=2.7
# Python 3.4
$ conda create -n tensorflow python=3.4
激活tensorflow环境,然后使用其中的 pip 安装 TensorFlow. 当使用easy_install使用--ignore-installed标记防止错误的产生。
$ source activate tensorflow
(tensorflow)$
# Your prompt should change
# Ubuntu/Linux 64-bit, CPU only, Python 2.7:
(tensorflow)$ pip install --ignore-installed --upgrade https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-0.8.0rc0-cp27-none-linux_x86_64.whl
# Ubuntu/Linux 64-bit, GPU enabled, Python 2.7. Requires CUDA toolkit 7.5 and CuDNN v4.
# For other versions, see "Install from sources" below.
(tensorflow)$ pip install --ignore-installed --upgrade https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow-0.8.0rc0-cp27-none-linux_x86_64.whl
# Mac OS X, CPU only:
(tensorflow)$ pip install --ignore-installed --upgrade https://storage.googleapis.com/tensorflow/mac/tensorflow-0.8.0rc0-py2-none-any.whl
对于 Python 3.x :
$ source activate tensorflow
(tensorflow)$
# Your prompt should change
# Ubuntu/Linux 64-bit, CPU only, Python 3.4:
(tensorflow)$ pip install --ignore-installed --upgrade https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-0.8.0rc0-cp34-cp34m-linux_x86_64.whl
# Ubuntu/Linux 64-bit, GPU enabled, Python 3.4. Requires CUDA toolkit 7.5 and CuDNN v4.
# For other versions, see "Install from sources" below.
(tensorflow)$ pip install --ignore-installed --upgrade https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow-0.8.0rc0-cp34-cp34m-linux_x86_64.whl
# Mac OS X, CPU only:
(tensorflow)$ pip install --ignore-installed --upgrade https://storage.googleapis.com/tensorflow/mac/tensorflow-0.8.0rc0-py3-none-any.whl
conda 环境激活后,你可以
当你不用 TensorFlow 的时候,关闭环境:
(tensorflow)$ source deactivate
# Your prompt should change back
再次使用的时候再激活 :-)
$ source activate tensorflow
(tensorflow)$
# Your prompt should change.
# Run Python programs that use TensorFlow.
# When you are done using TensorFlow, deactivate the environment.
(tensorflow)$ source deactivate
尝试你的第一个 TensorFlow 程序
(可选) 启用 GPU 支持
如果你使用 pip 二进制包安装了开启 GPU 支持的 TensorFlow, 你必须确保
系统里安装了正确的 CUDA sdk 和 CUDNN 版本. 请参间
你还需要设置 LD_LIBRARY_PATH 和 CUDA_HOME 环境变量. 可以考虑将下面的命令
添加到 ~/.bash_profile 文件中, 这样每次登陆后自动生效. 注意, 下面的命令
假定 CUDA 安装目录为 /usr/local/cuda:
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda/lib64"
export CUDA_HOME=/usr/local/cuda
运行 TensorFlow
打开一个 python 终端:
&&& import tensorflow as tf
&&& hello = tf.constant('Hello, TensorFlow!')
&&& sess = tf.Session()
&&& print sess.run(hello)
Hello, TensorFlow!
&&& a = tf.constant(10)
&&& b = tf.constant(32)
&&& print sess.run(a+b)
从源码安装
克隆 TensorFlow 仓库
$ git clone --recurse-submodules https://github.com/tensorflow/tensorflow
--recurse-submodules 参数是必须得, 用于获取 TesorFlow 依赖的 protobuf 库.
Linux 安装
安装 Bazel
安装 Bazel 的依赖.
中下载适合你的操作系统的最新稳定版,
最后按照下面脚本执行：
$ chmod +x PATH_TO_INSTALL.SH
$ ./PATH_TO_INSTALL.SH --user
注意把 PATH_TO_INSTALL.SH 替换为你下载的安装包的文件路径.
将执行路径 output/bazel 添加到 $PATH 环境变量中.
安装其他依赖
# For Python 2.7:
$ sudo apt-get install python-numpy swig python-dev python-wheel
# For Python 3.x:
$ sudo apt-get install python3-numpy swig python3-dev python3-wheel
可选: 安装 CUDA (在 Linux 上开启 GPU 支持)
为了编译并运行能够使用 GPU 的 TensorFlow, 需要先安装 NVIDIA 提供的 Cuda Toolkit 7.0
和 CUDNN 6.5 V2.
TensorFlow 的 GPU 特性只支持 NVidia Compute Capability &= 3.5 的显卡. 被支持的显卡
包括但不限于:
NVidia Titan
NVidia Titan X
NVidia K20
NVidia K40
下载并安装 Cuda Toolkit 7.0
将工具安装到诸如 /usr/local/cuda 之类的路径.
下载并安装 CUDNN Toolkit 6.5
解压并拷贝 CUDNN 文件到 Cuda Toolkit 7.0 安装路径下. 假设 Cuda Toolkit 7.0 安装
在 /usr/local/cuda, 执行以下命令:
tar xvzf cudnn-6.5-linux-x64-v2.tgz
sudo cp cudnn-6.5-linux-x64-v2/cudnn.h /usr/local/cuda/include
sudo cp cudnn-6.5-linux-x64-v2/libcudnn* /usr/local/cuda/lib64
配置 TensorFlow 的 Cuda 选项
从源码树的根路径执行:
$ ./configure
Do you wish to bulid TensorFlow with GPU support? [y/n] y
GPU support will be enabled for TensorFlow
Please specify the location where CUDA 7.0 toolkit is installed. Refer to
README.md for more details. [default is: /usr/local/cuda]: /usr/local/cuda
Please specify the location where CUDNN 6.5 V2 library is installed. Refer to
README.md for more details. [default is: /usr/local/cuda]: /usr/local/cuda
Setting up Cuda include
Setting up Cuda lib64
Setting up Cuda bin
Setting up Cuda nvvm
Configuration finished
这些配置将建立到系统 Cuda 库的符号链接. 每当 Cuda 库的路径发生变更时, 必须重新执行上述
步骤, 否则无法调用 bazel 编译命令.
编译目标程序, 开启 GPU 支持
从源码树的根路径执行:
$ bazel build -c opt --config=cuda //tensorflow/cc:tutorials_example_trainer
$ bazel-bin/tensorflow/cc/tutorials_example_trainer --use_gpu
# 大量的输出信息. 这个例子用 GPU 迭代计算一个 2x2 矩阵的主特征值 (major eigenvalue).
# 最后几行输出和下面的信息类似.
005 lambda = 2.000000 x = [0..447214] y = [1..894427]
001 lambda = 2.000000 x = [0..447214] y = [1..894427]
009 lambda = 2.000000 x = [0..447214] y = [1..894427]
注意, GPU 支持需通过编译选项 &--config=cuda& 开启.
尽管可以在同一个源码树下编译开启 Cuda 支持和禁用 Cuda 支持的版本, 我们还是推荐在
在切换这两种不同的编译配置时, 使用 &bazel clean& 清理环境.
在执行 bazel 编译前必须先运行 configure, 否则编译会失败并提示错误信息. 未来,
我们可能考虑将 configure 步骤包含在编译过程中, 以简化整个过程, 前提是 bazel 能够提供新的特性支持这样.
Mac OS X 安装
Mac 和 Linux 需要的软件依赖完全一样, 但是安装过程区别很大. 以下链接用于帮助你
在 Mac OS X 上安装这些依赖:
参见的 Mac OS X 安装指南.
注意: 你需要安装,
而不是 PCRE2.
创建 pip 包并安装
$ bazel build -c opt //tensorflow/tools/pip_package:build_pip_package
$ bazel-bin/tensorflow/tools/pip_package/build_pip_package /tmp/tensorflow_pkg
# .whl 文件的实际名字与你所使用的平台有关
$ pip install /tmp/tensorflow_pkg/tensorflow-0.5.0-cp27-none-linux_x86_64.whl
训练你的第一个 TensorFlow 神经网络模型
从源代码树的根路径执行:
$ cd tensorflow/models/image/mnist
$ python convolutional.py
Succesfully downloaded train-images-idx3-ubyte.gz 9912422 bytes.
Succesfully downloaded train-labels-idx1-ubyte.gz 28881 bytes.
Succesfully downloaded t10k-images-idx3-ubyte.gz 1648877 bytes.
Succesfully downloaded t10k-labels-idx1-ubyte.gz 4542 bytes.
Extracting data/train-images-idx3-ubyte.gz
Extracting data/train-labels-idx1-ubyte.gz
Extracting data/t10k-images-idx3-ubyte.gz
Extracting data/t10k-labels-idx1-ubyte.gz
Initialized!
Epoch 0.00
Minibatch loss: 12.054, learning rate: 0.010000
Minibatch error: 90.6%
Validation error: 84.6%
Epoch 0.12
Minibatch loss: 3.285, learning rate: 0.010000
Minibatch error: 6.2%
Validation error: 7.0%
GPU 相关问题
如果在尝试运行一个 TensorFlow 程序时出现以下错误:
ImportError: libcudart.so.7.0: cannot open shared object file: No such file or directory
请确认你正确安装了 GPU 支持, 参见 .
在 Linux 上
如果出现错误:
"__add__", "__radd__",
SyntaxError: invalid syntax
解决方案: 确认正在使用的 Python 版本为 Python 2.7.
在 Mac OS X 上
如果出现错误:
import six.moves.copyreg as copyreg
ImportError: No module named copyreg
解决方案: TensorFlow 使用的 protobuf 依赖 six-1.10.0. 但是, Apple 的默认 python 环境
已经安装了 six-1.4.1, 该版本可能很难升级. 这里提供几种方法来解决该问题:
升级全系统的 six:
sudo easy_install -U six
通过 homebrew 安装一个隔离的 python 副本:
brew install python
在 内编译或使用 TensorFlow.
如果出现错误:
&&& import tensorflow as tf
Traceback (most recent call last):
File "&stdin&", line 1, in &module&
File "/usr/local/lib/python2.7/site-packages/tensorflow/__init__.py", line 4, in &module&
from tensorflow.python import *
File "/usr/local/lib/python2.7/site-packages/tensorflow/python/__init__.py", line 13, in &module&
from tensorflow.core.framework.graph_pb2 import *
File "/usr/local/lib/python2.7/site-packages/tensorflow/core/framework/tensor_shape_pb2.py", line 22, in &module&
serialized_pb=_b('\n,tensorflow/core/framework/tensor_shape.proto\x12\ntensorflow\"d\n\x10TensorShapeProto\x12-\n\x03\x64im\x18\x02 \x03(\x0b\x32 .tensorflow.TensorShapeProto.Dim\x1a!\n\x03\x44im\x12\x0c\n\x04size\x18\x01 \x01(\x03\x12\x0c\n\x04name\x18\x02 \x01(\tb\x06proto3')
TypeError: __init__() got an unexpected keyword argument 'syntax'
这是由于安装了冲突的 protobuf 版本引起的, TensorFlow 需要的是 protobuf 3.0.0. 当前
最好的解决方案是确保没有安装旧版本的 protobuf, 可以使用以下命令重新安装 protobuf 来解决
brew reinstall --devel protobuf