流处理器

java I/O库中设计模式的应用

阅读更多关于 java I/O库中设计模式的应用

3 月，跳不动了？>>> 在java语言 I/O库的设计中，使用了两个结构模式，即装饰模式和适配器模式。在任何一种计算机语言中，输入/输出都是一个很重要的部分。与一般的计算机语言相比，java将输入/输出的功能和使用范畴做了很大的扩充。因此输入输出在java语言中占有极为重要的位置。 java语言采用流的机制来实现输入/输出。所谓流，就是数据的有序排列，流可以是从某个源（称为流源，或者 Source of Stream）出来，到某个目的（Sink of Stream）地去。根据流的方向可以将流分成输出流和输入流。程序通过输入流读取数据，想输出流写出数据。例如：一个java程序可以使用FileInputStream类从一个磁盘文件读取数据，如下图：像FileInputStream这样的处理器叫流处理器。一个流处理器就像一个流的管道一样，从一个流源吸入某种类型的数据，并输出某种类型的数据。上面的示意图叫流的管道图。类似地，也可以用FileOutputStream类向一个磁盘文件写数据，如下图：在实际的应用当中，这样简单的机制并没有太大的用处。程序需要写出的往往是非常结构话的信息，因此这些Byte类型的数据实际上是一些数字、文字、源代码等。java的I/O库提供了一个称作链接（Chaining）的机制，可以将一个流处理器与另一个流处理器首尾相接，以其中之一的输出为输入

GPU物理架构

阅读更多关于 GPU物理架构

目前市场上的 NVIDIA 显卡都是基于 Tesla 架构的，分为 G80 、 G92 、 GT200 三个系列。 Tesla 体系架构是一块具有可扩展处器数量的处理器阵列。每个 GT200 GPU 包含 240 个流处理器（ streaming processor,SP ），每 8 个流处理器又组成了一个流多处理器 (streaming multiprocessor,SM) ，因此共有 30 个流多处理器。 GPU 在工作时，工作负载由 PCI-E 总线从 CPU 传入 GPU 显存，按照体系架构的层次自顶向下分发。PCI-E 2.0规范中，每个通道上下行的数据传输速度达到了 5.0Gbit/s ，这样 PCI-E2.0 × 16 插槽能够为上下行数据各提供了 5.0*16Gbit/s=10GB/s 的带宽，故有效带宽为 8GB/s, 而 PCI-E 3.0 规范的上下行数据带宽各为 20GB/s 。但是由于 PCI-E 数据封包的影响，实际可用的带宽大约在 5-6GB/s （ PCI-E 2.0 ×16 ）。在 GT200 架构中，每 3 个 SM 组成一个 TPC （ Thread Processing Cluster ，线程处理器集群），而在 G80 架构中，是两个 SM 组成一个 TPC ， G80 里面有 8 个 TPC ，因为 G80 有 128(2*8*8)

Java I/O库的设计分析

阅读更多关于 Java I/O库的设计分析

Java采用了流的机制来实现输入／输出。所谓流，就是数据的有序排列。而流可以是从某个源（称为流源或Source of Stream）出来，到某个目的地（称为流汇或Sink of Stream）去的。由流的方向，可以分成输入流和输出流。一个程序从输入流读取数据向输出流写数据。流处理器所处理的流必定都有流源，而如果将流类所处理的流源分类的话，基本可以分成两大类：　第一　数组，String，File等，这一种叫原始流源。　第二　同样类型的流用做链接流类的流源，叫链接流源。 Java语言的I/O库是对各种常见的流源，流汇以及处理过程的抽象化。客户端的Java程序不必知道最终的流源，流汇是磁盘上的文件还是数组等；（原始流）也不必关心数据是否经过缓冲的，可否按照行号读取等处理的细节。（链接流）要理解Java I/O这个庞大而复杂的库，关键是要掌握两个对称性跟两个设计模式。 Java I/O库具有两个对称性，它们分别是：　１　输入－输出对称性：　　　　比如InputStream和OutputStream各自占据Byte流的输入与输出的两个平行的等级结构的根部。　　　　而Reader和Writer各自占据Char流的输入与输出的两个平行的等级结构的根部。　２　byte-char对称：　　　

Java IO 流设计模式

阅读更多关于 Java IO 流设计模式

学过装饰模式后，大家会发现，它在Java语言中最著名的应用莫过于Java I/O标准为库的设计了。这一节将以处理Byte流为例，看看装饰模式是怎样得到应用的。　为什么不用继承而用装饰模式　我们知道Java I/O库需要很多性能的各种组合，如果说这些性能的组合是通过继承方式来实现的话，那么每一种组合都需要一个类，这样就会出现大量重复性问题的出现，从而使类数目“爆炸”。而如果采用装饰模式，那么不仅类的数目大减少了，性能的重复也可以减至到最少。所以装饰模式是Java I/O库的基本模式。在这里我想再用<<Head First Design Pattern>>中讲到装饰模式时候的一个例子，看看装饰模式是怎么达到不仅类的数目大减少了，性能的重复也可以减至到最少：　它这个例子大概是说：Beverage是一个抽象类，它被所有在一个咖啡店里卖的饮料继承。Beverage有个抽象方法cost，所有的子类都要实现这个抽象方法，计算它们的价格。现在有四个最基本的咖啡：HouseBlend,DarkRoast,Decaf,Espresso他们都继承自Beverage，现在的需求是说在四个最基本的咖啡里，每个都可以随便地添加调味品，像steamed milk,soy,还有mocha最后是加上whipped milk。如果是说按继承来实现这种几个调味品跟原来咖啡的组合的话

流处理认识

阅读更多关于流处理认识

浅谈流处理什么是流处理流处理是一种大数据处理技术。它使用户能够查询连续数据流，并在从接收数据开始很短的时间内快速检测条件。检测时间从几毫秒到几分钟不等。例如，通过流处理，你可以通过查询来自温度传感器的数据流并检测温度何时达到冻结点来接收警报。它还有许多名称：实时分析、流分析、复杂事件处理、实时流分析和事件处理。尽管一些术语在历史上存在差异，但现在工具（框架）在术语流处理下已经趋于一致。（有关框架的列表和本文的最后一节以了解历史，请参阅这个 Quora问题）它通过 Apache Storm 作为一种像 Hadoop 一样能够快速给出结果的技术得以普及，之后它被当作一种大数据技术采用。现在有很多竞争者。为什么需要流处理从处理数据中得出的见解(insights)是有价值的。这样的见解(insights)并非都是生来平等的。一些见解(insights)在发生后不久就具有很高的价值，并且随着时间的流逝，这种价值会迅速减少。流处理针对这样的场景。流处理的关键优势在于它能够更快地提供见解(insights)，通常在毫秒到秒之间。下面是使用流处理的一些次要原因。原因1: 有些数据自然地以永无止境的事件流出现。要进行批处理，需要存储它、在某个时间停止数据收集并处理数据。然后你必须执行下一批操作，然后担心跨多个批进行聚合。相比之下，流处理永无止境的数据流更优雅、更自然。你可以检测模式

JAVA IO 设计模式彻底分析

阅读更多关于 JAVA IO 设计模式彻底分析

一。引子（概括地介绍Java的ＩＯ）　　无论是哪种编程语言，输入跟输出都是重要的一部分，Java也不例外，而且Java将输入／输出的功能和使用范畴做了很大的扩充。它采用了流的机制来实现输入／输出，所谓流，就是数据的有序排列，而流可以是从某个源（称为流源或Source of Stream）出来，到某个目的地（称为流汇或Sink of Stream）去的。由流的方向，可以分成输入流和输出流，一个程序从输入流读取数据向输出流写数据。　　如，一个程序可以用FileInputStream类从一个磁盘文件读取数据，如下图所示：　　像FileInputStream这样的处理器叫做流处理器，它就像流的管道一样，从一个流源吸入某种类型的数据，并输出某种类型的数据。上面这种示意图叫做流的管道图。　　同样道理，也可以用FileOutputStream类向一个磁盘文件写数据，如下图所示：　　在实际应用这种机制并不没有太大的用处，程序需要写出地通常是非常结构化的信息，因此这些byte类型的数据实际上是一些数值，文字，源代码等。Java的I/O库提供了一个称做链接（Chaining）的机制，可以将一个流处理器跟另一个流处理器首尾相接，以其中之一的输出为输入，形成一个流管道的链接。　　例如，DataInputStream流处理器可以把FileInputStream流对象的输出当作输入

订阅流处理器