i7源码

① 求高手编写一个通达信用：个股每日“成交额”的指标源码

总购买量：dynainfo (23) * C；
总销售额：dynainfo (22) * C；
Stickline（总购买金额 < > 0，0，总购买金额，5，0），颜色为红色；
Stickline（总销售额 < > 0，总购买量，总销售额，5，0），颜色绿色；
Stickline（总购买量，0，0，总购买量，5，0），红色
详细信息：操作数没有对应的运算符匹配！
错误起始位置：48； 长度：1
拓展资料
1.股票技术指标属于统计范畴。它们是一些用来衡量一切的数据指标，用数据来展示股票走势、交易等。通过指数代码，股票软件可以用公式自动计算出股票技术指数。估计只能手动操作了。
2.首先选择通大信报价，按7，选择深沪A股，列出股票，点击上方的增加一两次。一次按股价涨幅排列股票后，在屏幕上右击选择“批量操作”，在新对话框中选择“全选”，然后“添加到板块”和“新板块”，然后重复上一步，依次将90只股票加入新版块，返回通大信报价主界面，中下边自定义。单击后，将出现列表。选择刚才新建的板块，90只股票都在里面。在菜单栏中选择第二个“功能”，选择“报价分析”。左上角有一个尖锐的向下的小三角形。单击并选择“平均值”以等待计算。
3.除非您使用超级计算机，否则对垂直统计的需求会导致您的计算机速度急剧下降。一般计算机不推荐使用纵向统计。 i7没测试过，8核电脑测试过，涉及纵向统计。电脑只是卡住了。可以按指标排序，对交易金额进行排序，并附上上述指标。符合条件的另存为另一盘这比那快得多
4.股票是股份公司发行的所有权凭证，是股份公司为筹集资金而发行给各个股东作为持股凭证并借以取得股息和红利的一种有价证券。每股股票都代表股东对企业拥有一个基本单位的所有权。每支股票背后都有一家上市公司。换言之，每家上市公司都会发行股票。同一类别的每一份股票所代表的公司所有权是相等的。每个股东所拥有的公司所有权份额的大小，取决于其持有的股票数量占公司总股本的比重。股票是股份公司资本的构成部分，可以转让、买卖或作价抵押，是资本市场的主要长期信用工具，但不能要求公司返还其出资。
5.股票投资是一种没有期限的长期投资。股票一经买入，只要在股票发行公司存在，任何股票持有者都不能退股，即不能向股票发行公司要求抽回本金。同样，股票持有者的股东身份和股东权益就不能改变，但他可以通过股票交易市场将股票卖出，使股份转让给其他投资者，以收回自己原来的投资。

② solr和elasticsearch对比，有啥差别吗

从两个方面对ElasticSearch和Solr进行对比，从关系型数据库中的导入速度和模糊查询的速度。

单机对比

1. Solr 发布了4.0-alpha，试了一下，发现需要自己修改schema，好处是它自带一个data importer。在自己的计算机上测试了一下，导入的性能大概是：14分钟导入 3092730 条记录，约合 3682条/秒。

2. 3百万条记录的情况下，模糊查询和排序基本都在1秒内返回

3. 刚才的测试，是每个field单独存储，现在修改了一下配置文件，增加了一个Field，所有的field都拷贝一份到text这个field里面去，导入的性能大概是：19分钟导入了3092730 条记录，约合 2713条/秒

4. 3百万条记录的情况下，针对text的模糊查询基本在1秒内返回，但是针对所有记录的排序，大概要2~3秒

5. 使用 elasticsearch 0.19.8，缺省配置，用单任务导入，导入性能是：20分钟导入了3092730 条记录，约合2577条/秒

6. 3百万条记录的情况下，查询基本上在1秒内返回，但是模糊查询比较慢，第一次要10秒，后来大概要1~3秒。加上排序大概需要5秒，整体排序基本100ms

查询及排序的指令：

{

"query": {

"query_string": {

"query": "*999*"

}

},

"sort": [

{

"TIME_UP": {

"order": "asc"

}

}

]

}

7. Es0.19.8，用两个任务导入，导入性能是：13分钟导入了3092730 条记录，约合3965条/秒

8. Solr全部建好索引后，占用磁盘空间是1.2G，es占用磁盘空间是4G

单机对比2

在一台Intel i7，32G内存的机器上，重新跑这两个的对比。不过有个重大的区别在于，Solr是在这台性能很好的机器上跑，而es的导入进程则是在一台Intel 四核 2.5G，4G内存的机器上跑的，也许会有性能的差异。ES版本0.19.8，Solr版本4.0-ALPHA。

1. Solr的导入性能：3400万条记录，用时62分钟，平均9140条/秒，占用空间12.75G

2. 使用 *999* 这样的模糊查询，3秒以内返回，稍长一点的查询条件 *00100014*，也是2~3秒返回

3. Es的导入性能（设置Xmx为10G）：3400万条记录，用时40分钟，平均14167条/秒，占用空间33.26G，客户端采用4个并发。

4. 使用 *999* 这样的模糊查询，9秒返回，稍长一点的查询条件 *00100014*，11.8秒返回

5. 如果不是针对所有字段查询，而是针对某个特定字段，比如 SAM_CODE: *00100014*，那么也是1秒以内返回。

6. 结论：es的查询效率也可以很高，只是我们还不会用。

7. 结论2：es有个设置是把所有字段放一块的那个，缺省是放一起，但是不知道为什么没起到应有的作用。

备注：

1. Solr第一次的那个内存使用的是缺省设置，这次改为10G，结果导入性能反而变差了，400万条记录，用了8分钟，平均8333条/秒，不知道为什么。

2. 改回缺省的内存配置，导入速度仍然慢。

3. 重启Linux，用10G的内存配置，再导入，5030万条记录，用时92分，约9112条/秒，说明导入速度和内存配置没有大差别

4. 在10G配置的情况下，检索速度也差别不大。

5. 为了搞清楚lucene4.0和solr4.0的进步有多大，下载了solr3.6.1，所幸的是4.0的配置文件在3.6.1上也可以用，所以很快就搭起来进行测试，导入性能为：3400万条记录，用时55分钟，约10303条/秒，占用空间13.85G。查询性能：*999*第一次11.6s，*00100014* 27.3s，相比4.0ALPHA的结果（5000万结果当中，*999*第一次2.6s，*00100014*第一次2.5s）来说，慢了很多，与es的性能差不多，因此，也许lucene4.0真的对性能有大幅提升？

集群对比：

采用4台同样配置（Intel i7，32G内存）的Centos 6.3组成的集群，进行对比。

1. 首先是es，很方便的就组成了一个Cluster，等上一个3400万条的Index全部均衡负载之后进行测试，导入到另外一个Index当中。

2. 导入性能：8500万条记录，用时72分钟，约为19676条/秒。在前5千万条记录导入时的速度在2万/条以上，初始的速度在2.2万/条。占用空间78.6G（由于有冗余，实际占用空间为157.2G）

3. 查询性能：

*999*第一次13.5秒，第二次19.5秒，第三次7.4秒，第四次7.1秒，第五次7.1秒

*00100014*第一次17.2秒，第二次16.6秒，第三次17.9秒，第四次16.7秒，第五次17.1秒

SAM_CODE:*999*，0.8s，1.3s，0.02s，0.02s，0.02s

SAM_CODE: *00100014*，0.1s，0.1s，0.02s，0.03s，0.05s

4. Solr4.0-ALPHA，SolrCloud的配置还算简单，启动一个ZooKeeper，然后其他三台机器访问这个地址，就可以组成一个Cloud：

机器1： nohup java -Xms10G -Xmx10G -Xss256k -Djetty.port=8983 -Dsolr.solr.home="./example-DIH/solr/" -Dbootstrap_confdir=./example-DIH/solr/db/conf/ -Dcollection.configName=xabconf3 -DzkRun -DnumShards=4 -jar start.jar &

其他机器：nohup java -Xms10G -Xmx10G -Dsolr.solr.home="./example-DIH/solr/" -DzkHost=192.168.2.11:9983 -jar start.jar &

但是在执行 data import 的时候，频繁出现 OutOfMemoryError: unable to create new native thread。查了很多资料，把Linux的ulimit当中的nproc改成10240，把Xss改成256K，都解决不了问题。暂时没有办法进行。

结论

1. 导入性能，es更强

2. 查询性能，solr 4.0最好，es与solr 3.6持平，可以乐观的认为，等es采用了lucene4之后，性能会有质的提升

3. Es采用SAM_CODE这样的查询性能很好，但是用_all性能就很差，而且差别非常大，因此，个人认为在目前的es情况下，仍然有性能提升的空间，只是现在还没找到方法。

③ 一分钟之内让cpu烧毁的代码有木有

您好，我来自英特尔中国研究中心研发部，有幸回答您的问题。
去年，处理器内置的防病毒硬件截获了一个代码，他可以使处理器不断循环解析，导致CPU资源大量占用，但是这个源代码是以JAVA应用程序的二进制64位源代码。
,目前所有处理器都免疫病毒以及恶意代码。
英特尔与你共创未来。

④ i73930K为什么比其它6核处理器便宜得多有什么缺点吗

因为主流应用没有这个数据量。多核心、多线程CPU要发挥性能，前提是必须要有足够多的线程。但多线程开发是个坑活，不是简单fork出来个线程就能多线程的。数据锁定、同步、线程间通信，全都是坑。

单核性能是上不去，但事实上是你不玩大型游戏、多开挂机，不剪视频，不搞3D渲染，不玩虚拟机集群，不三天两头编译一个GCC级别的应用，轻薄本上的4核CPU都没什么机会满载，除了屏幕小点外，很多人根本不觉得轻薄本和台式机使用上有什么区别。

只有数据量足够大了，例如1080P 24FPS规格的视频解码后一分钟有近9 GB数据，需要对如此大量的数据进行压缩编码的视频剪辑；根据3D模型和纹理光源设置渲染出这个数据量的CG渲染，类似这样的天然就是海量数据的应用，才会有大批数据可以用相同的处理过程去分批处理——然后很自然就可以用多个线程，每个线程处理一批，最后汇总结果即可。或者是超过10W个源码文件的GCC——通常是编译后还要用编译出来的二进制程序再编译一到两次，天然就是大量任务并且每个任务可以用独立线程处理。

需要说一下的是虽然大型3D游戏也是需要实时渲染出这个数据量的画面，而且往往数据更大量——毕竟24 FPS的游戏体验很差，60 FPS都不一定满意，144 FPS还没到头。但大部分计算是由GPU负担，CPU只是处理一些GPU不方便处理的计算以及运行GPU的驱动程序而已。这些GPU不方便处理的计算任务通常包括但不限于用户输入响应、网络数据传输、游戏AI等，每一项任务都可以分配给不同的线程去处理，但单项任务往往不适合再进一步拆分开来使用多个线程来处理——适合多线程处理的任务通常也适合用性能更强的GPU计算。这些任务的数量总是有限的，某些任务的计算量是很小的，因此CPU核心再多往往也无法发挥。