由买买提看人间百态

topics

全部话题 - 话题: 应用层
首页 上页 1 2 3 4 5 6 7 8 下页 末页 (共8页)
h***m
发帖数: 1869
1
windows DDK有无线的api函数
m***t
发帖数: 254
2
来自主题: Programming版 - 今天和一个朋友瞎扯
本来是和朋友周五偷懒打foosball发牢骚,没想到上了首页。 大家看了笑笑就好, 千
万别当我对写javascript用webkit的人有什么不敬。作为程序员把技术或者自己当成商
品每天琢磨市场供需就太无趣了。 要向老乔学习, 没有市场的地方去创造市场。 没
有啥底层应用层,只有killer products。
T*******x
发帖数: 8565
3
那倒是。
另外一个问题吧:
不过大致可以分为这么两个阶段:
基础的Data Structure阶段,和应用层面的algorithm阶段。
而且这两个阶段的确存在着一定的矛盾:
1.Data Structure阶段需要用到reference,
2.而algorithm阶段全部用值传参数最方便。
这样说对吧?
C***y
发帖数: 2546
4
来自主题: Programming版 - c++逐渐没落?
那是应用层
大部分核心程序都是C++的
g*****g
发帖数: 34805
5
来自主题: Programming版 - c++逐渐没落?
程序的单机运行效率随着硬件的进步越来越不重要,连手机都4核了,
这正是C++在应用层开发里没落的原因。
y**b
发帖数: 10166
6
来自主题: Programming版 - 求推荐:fortran好用的debug软件
你说的是底层的框架,我说的是些专业领域(应用层)的框架,比如地学的ESMF,
海洋学的ROMS, 有限元的TAHOE。
扯远点,我也想哪天搞个离散元的框架,再跟FEM耦合,再跟CFD耦合,不过个
人的时间精力能力都不允许,感觉这种东西只能是较大的专门的research group
一起干好多年才有戏,也不知这类group怎么搭建起来的。一般都是国家实验室
或著名的民间研究机构才搞得出这类东西,小的机构很难。
g*****g
发帖数: 34805
7
来自主题: Programming版 - 为什么大家都说c++水很深?
Amazon就是一个SOA为核心的架构。主要语言是Java, Perl, C++。Scalability的核心
是Sharding,跟Ebay并没有什么不同。有兴趣你可以看看这个。
http://highscalability.com/amazon-architecture
Perl, C++很多还是Legacy原因。后出的AWS在应用层上的代码基本上都是Java写的。
g*****g
发帖数: 34805
8
来自主题: Programming版 - 为什么大家都说c++水很深?
Amazon就是一个SOA为核心的架构。主要语言是Java, Perl, C++。Scalability的核心
是Sharding,跟Ebay并没有什么不同。有兴趣你可以看看这个。
http://highscalability.com/amazon-architecture
Perl, C++很多还是Legacy原因。后出的AWS在应用层上的代码基本上都是Java写的。
g*****g
发帖数: 34805
9
即使不在server上。从desktop到mobile,内存增长的速度可比程序发展需要的涨得快。
PC上desktop app开发的首选语言是C#。最大的mobile平台的首选语言是Java,都是有
VM的。
这就是个趋势,绝大多数应用层开发,最后都会转向基于VM的语言,需要手工内存管理
的应用只会越来越少。这年头,连相机家电都开始跑Android。
g*****g
发帖数: 34805
10
你说得不错,问题是java根本不用来做这些。嫌弃java慢又从何说起。
要比,自然要比C++和Java都能做的应用层,否则完全鸡同鸭讲。
a*****e
发帖数: 1700
11
来自主题: Programming版 - functional programming?
如果你要问我,我会说几乎没有什么是 FP 不适合的,就连内核以及嵌入式,FPGA 等
都有 FP 的解决方案。
这里我并不是说内核或者嵌入设备去跑 FP 语言的 runtime,而是说用 FP 的工具设计
的 DSL 跑在内核和嵌入设备上。比如你可以搜一下 se4L,它的一个实现是用 Haskell
写的,被用于证明所生成的内核的正确性。
I'm a big believer in DSL. 合理设计的 DSL 能够快速完成目标 domain 的编程要求
,所需要的只是一个有效的 DSL 开发环境,FP 在这方面非常适合。就象是一套合理设
计的库函数或者框架什么的,能够大幅度提高开发效率。但是库函数的组合调用通常都
是写在源程序里,写好就不可以改动。而 DSL 则是它本身可以被分析重组,写好之后
,还可以用程序处理变换,验证性质,生成高效代码等。元语言 (meta programming)
的技术目前也在抬头,但我认为还是 DSL 更灵活,因为 meta programming 所操作的
对象还是一个 general purpose 的语言所写的程序结构,很多时候我们只需要 domai... 阅读全帖
t*****n
发帖数: 4908
12
来自主题: Programming版 - functional programming?
这方面,采取 immutable 的数据结构也会更适合 modern CPU,比如 cache-friendly
(sharing, no read/write barrier),比如 SIMD ,比如 thread 间数据的交换,可
以尽量避免 CAS 等。就连 Garbage Collection 也可以针对 cache 进行优化,而不需
要修改应用层面的东西。Scientific Computing 很多时候追求高效,结果把 C 或者
Fortran 的源程序调得乱糟糟,事后很难维护,长远来看是得不偿失的。
真能码字。不过计算远没有你想的那么差。只有低水平的编程者,没有生来就乱的语言
。高手写的fortran,远胜入门者写的fp。

Haskell
)
a*****e
发帖数: 1700
13
来自主题: Programming版 - functional programming?
如果你要问我,我会说几乎没有什么是 FP 不适合的,就连内核以及嵌入式,FPGA 等
都有 FP 的解决方案。
这里我并不是说内核或者嵌入设备去跑 FP 语言的 runtime,而是说用 FP 的工具设计
的 DSL 跑在内核和嵌入设备上。比如你可以搜一下 se4L,它的一个实现是用 Haskell
写的,被用于证明所生成的内核的正确性。
I'm a big believer in DSL. 合理设计的 DSL 能够快速完成目标 domain 的编程要求
,所需要的只是一个有效的 DSL 开发环境,FP 在这方面非常适合。就象是一套合理设
计的库函数或者框架什么的,能够大幅度提高开发效率。但是库函数的组合调用通常都
是写在源程序里,写好就不可以改动。而 DSL 则是它本身可以被分析重组,写好之后
,还可以用程序处理变换,验证性质,生成高效代码等。元语言 (meta programming)
的技术目前也在抬头,但我认为还是 DSL 更灵活,因为 meta programming 所操作的
对象还是一个 general purpose 的语言所写的程序结构,很多时候我们只需要 domai... 阅读全帖
t*****n
发帖数: 4908
14
来自主题: Programming版 - functional programming?
这方面,采取 immutable 的数据结构也会更适合 modern CPU,比如 cache-friendly
(sharing, no read/write barrier),比如 SIMD ,比如 thread 间数据的交换,可
以尽量避免 CAS 等。就连 Garbage Collection 也可以针对 cache 进行优化,而不需
要修改应用层面的东西。Scientific Computing 很多时候追求高效,结果把 C 或者
Fortran 的源程序调得乱糟糟,事后很难维护,长远来看是得不偿失的。
真能码字。不过计算远没有你想的那么差。只有低水平的编程者,没有生来就乱的语言
。高手写的fortran,远胜入门者写的fp。

Haskell
)
S**I
发帖数: 15689
15
来自主题: Programming版 - JAVA vs C/C++之争, 我来做个小结吧
Windows应用层的代码确实大量使用C++,但是内核基本是纯C(加少量汇编);微软自
己都不认为在OS内核里使用C++是个好主意。
尽管看起来很像,但C和C++是两种完全不同的生物,不要混为一谈。
g*****g
发帖数: 34805
16
不是说你老板不牛哈。但是那么辛苦才提高50%效率。
我老上一份工作,用了三个月解决了一系列线程调度问题,用了些cache改进了一下架
构,性能就提高了10倍。一个产品从上线要赔钱,变成最后赚了几千万。
要实现价值,在应用层机会多很多哈。
h***s
发帖数: 1716
17
来自主题: Programming版 - 谈谈想学好底层必不可少的东西
本人对底层完全不懂,对架构等也不熟。。。就是好奇想知道,当前工业界,底层真的
没什么大发展了?
我倒是觉得,在平行计算这块,海量核(成千上万)的GPU芯片,无疑是今后有需求的
。现在流行的基于cluster的平行计算,每个节点上都不是高性能的GPU。至于说,需不
需要GPU,这个应该不是个疑问。。。当然,这个在应用层毫无疑问可以做,现有的几
个商用产品就是这样的。
"发信人: prognew (prog new), 信区: Programming
标 题: Re: 我来说说为什么现在做底层前途不大
发信站: BBS 未名空间站 (Sun Sep 29 17:14:14 2013, 美东)
底层关键技术在上个10年都解决了,或者都垄断了。不需要大量人力了。。"
p*****w
发帖数: 429
18
来自主题: Programming版 - 谈谈想学好底层必不可少的东西
gpgpu火过了已经。

本人对底层完全不懂,对架构等也不熟。。。就是好奇想知道,当前工业界,底层真的
没什么大发展了?
我倒是觉得,在平行计算这块,海量核(成千上万)的GPU芯片,无疑是今后有需求的
。现在流行的基于cluster的平行计算,每个节点上都不是高性能的GPU。至于说,需不
需要GPU,这个应该不是个疑问。。。当然,这个在应用层毫无疑问可以做,现有的几
个商用产品就是这样的。
"发信人: prognew (prog new), 信区: Programming
标 题: Re: 我来说说为什么现在做底层前途不大
发信站: BBS 未名空间站 (Sun Sep 29 17:14:14 2013, 美东)
底层关键技术在上个10年都解决了,或者都垄断了。不需要大量人力了。。"
h***s
发帖数: 1716
19
来自主题: Programming版 - 谈谈想学好底层必不可少的东西
我的意思是,GGPU这个大市场,还没有被谁完全垄断。尤其是具有通用性的系统(就算
在应用层也行),还是有很大市场潜力的。现在海量数据和各种复杂算法,不管在哪层
,都会越来越多。所以基于这种高性能并行的通用系统,应该是很有市场的,而且这个
市场还没有谁垄断。
h***s
发帖数: 1716
20
来自主题: Programming版 - 谈谈想学好底层必不可少的东西
现在的架构鼓励这么做,也可以算一种缺点吧;正是这些年CPU的硬件变化不大,所以
都开始做多核的了。一个趋势就是,CPU arch和GPGPU arch杂化的系统,现在商用的都
是在应用层上。不知道在底层,有没有人在做这种通用系统开发的(尤其是商用的)。
。。比如,一个例子就是(KGPU):
http://code.google.com/p/kgpu/
T******7
发帖数: 1419
21
c/c++背景。应用层linux driver都写.
也会c#写过wpf
web的会ror.
java是学校project水平
c****3
发帖数: 10787
22
你算幸运的,JAVA的开源有很多大公司的人帮助搞定和修bug
我做通信的。算是Linux嵌入系统的应用层,也做C写的服务器应用。这块就没有那么幸
运了,经常要自己搞定。
不过你说的和订票相关的那些noSQL分布系统,象mongodb之类,基本也是C和C++写的,
项目时间也不长,这块我听同事讲,也是问题多多,不过还算修复及时。
N*n
发帖数: 456
23
刚好在看TB 10 年的架构。。
load balancer
L1 cache
L2 cache
然后才是应用层 server, etc.
而且要有容灾考虑
d****i
发帖数: 4809
24
哈,刚看到,QNX作为一种嵌入式实时操作系统,已经支持用HTML5来写应用层的应用了
,你可以用你喜欢的JS来写QNX上的应用软件,详情请看:
http://www.qnx.com/news/pr_5309_2.html
N******K
发帖数: 10202
25
本人搞图像分析 数据很大 会上G
tcp只能保证buffer你发出去的能收到 难道把buffer搞到文件上限 比如10G?
tcp是没有文件概念文件的 你得自己定义简单协议 比如 起始报文 终止报文
远程搞 可能出问题 应为应用层自己搞的协议太简单 弄不好 文件就散架了
所以说 远程就用ftp好了
REST这东西不是很熟 如果用来传文件 能上G 底层用的是tcp?

solution
g*****g
发帖数: 34805
26
来自主题: Programming版 - 你们不懂c++
C++是传统CPU bound应用的首选,但近年有很多松动。很大原因就是Hadoop和云计算的
出现。
C++的优势是运行快,大多数benchmark比Java快一倍。劣势是开发维护慢,往往慢一倍
都不只。稳定性差,一个core dump搞死整个应用。
云计算的出现,使得很小的公司也能使用很大的计算资源,Hadoop的出现使得机群并行
计算的门槛显著降低。由于整体计算成本的下降,这时候深挖单机潜力不再那么有吸引
力。因为运行时间本身也很重要。大量的公司晚上做计算,白天就要用这个结果,比如
dating网站算match。随着用户数的增加,一个基于cloud的集群计算可以无限扩展,而
基于单机的很快就不行了。在这种环境下,基于Java的应用,因为开发快,稳定,网络
通讯实现简单,基于JVM的并行处理类库多而突出。
在我看来,C++在应用层的空间是越来越小,越来越成为一个系统层的语言,跟C竞争。
d****i
发帖数: 4809
27
来自主题: Programming版 - 你们不懂c++
goodbug评价C++还算比较客观的,毕竟是见多识广的架构师。但是同样在云后端,如果
牵涉到的不仅仅是biz logic,而是很多科学计算的话,C++有巨大优势,再加上OpenMP
, OpenMPI并行库等等如虎添翼,和Java的biz logic正好绝配。C++的定位其实应该是
在系统层和C配合,在应用层和Java配合。
b*******s
发帖数: 5216
28
来自主题: Programming版 - 你们不懂c++
应用层的我觉得gc很好,其实c++的设计哲学就是非基础性的东西不进入语言特性
gc是比较高层的东西了,放到c++这样的语言里不合适
其实由于这个哲学,也长期导致c++的库比较贫乏,大家分别造轮子
不过现在社区也意识到了这个问题,st是稳定库,保证可以跨平台编译
boost是新特性比较多的库,保证试验新特性,大家都觉得好就进stl
gc主要是隐藏内存管理细节,在jvm这样不存在平台碎片化的情况下可以做优化
c++程序员比较习惯的是轻量化管理,ref count式的现在有实现进了标准库
而内存自己管理,恰恰是提高性能的主要手段,比如针对cache的优化,
经过优化的c++程序,在处理计算和内存操作较多的任务时
绝对不会像大多泛泛的benchmark一样只比java快一倍,而是要有数量级的差别
ref count的典型实现是shared_ptr和weak_ptr,其实其只是控制了其生存周期
overhead是非常低的,你可以读读源代码,仅仅是少量的运算
java本身就比native code多一层,而且是很重的一层,先天上你jvm能做到的native都
能做到,而你在jvm上还有一层,所以j... 阅读全帖
a*******n
发帖数: 18
29
来自主题: Programming版 - 。想转java了 求教
入行三年的嵌入式工程师感觉没有前途。。想转java了 求教大神从何开始?
c/c++写的很熟。会写linux driver。会应用层c++编程。os很熟。networking 比较熟
。database 很搓。
java学校写过1,2年,库什么的都忘差不多了,java编程风格估计也是没有。
j2ee玩过struts也都忘了,spring mvc不会。
python谢的比较熟悉,但是非常不喜欢,不想做python程序员,我是括号黨。缩进什么
的受不了。
前台的,知道一些html,css,ruby,rails.MVC
我先在想开始复习复习java. core java觉得2,3个月能写面试题。
人在东部大华盛顿地区。java工作很多。
请大牛指导指导都学点什么好?java怎么准备?
g*****g
发帖数: 34805
30
这种应用层的实现毫无压力,现成的就有,所谓数据库也不过是存metadata,Blob还是
另存文件罢了。
d****i
发帖数: 4809
31
你这个完全错误,好的Java程序员象goodbug这样的,对C,C++这样的底层语言都是很
了解的,虽然可能现在工作中不怎么用可能会生疏一点,但是明白了基础的一些概念对
理解上层的语言的概念帮助是非常大的,Java, Python等应用层语言都是建立在C的基
础上的。你不明白C里面的char实际上对应的是ASCII的8位整数,你对atoi就无从下手。

C学不好的更需要java.你的例子沒说服
g*****g
发帖数: 34805
32
应该说比较底层的语言,不用懂啥系统架构,第三方类库上来就可以干活了。
应用层的语言则相反,先要考虑系统架构,然后要考虑关键地方用啥轮子。
T********i
发帖数: 2416
33
来自主题: Programming版 - C++确实不适合做大项目
hoho。原来你以为我用网卡缓存存应用层消息?
你老板要知道了一定会表扬你。
b*******s
发帖数: 5216
34
来自主题: Programming版 - 10M persistent TCP connections
像狗家亚麻家优化比较有意义,做基础设施和做应用层的不一样
b*******s
发帖数: 5216
35
来自主题: Programming版 - 10M persistent TCP connections
他们做的相当于传统意义上的中间件和应用层
b*******s
发帖数: 5216
36
来自主题: Programming版 - 10M persistent TCP connections
像狗家亚麻家优化比较有意义,做基础设施和做应用层的不一样
b*******s
发帖数: 5216
37
来自主题: Programming版 - 10M persistent TCP connections
他们做的相当于传统意义上的中间件和应用层
g*****g
发帖数: 34805
38
来自主题: Programming版 - 10M persistent TCP connections
你就别撑了, Robert提了几点。一个是要从 driver开始写,一个是根据应用不同对
network stack 选择性实现,或者部分支持,以达最简目的。还有一个就是没有任何开
源可靠的user space TCP/IP实现,所以你只能自己写。
nginx支持 http, 因为 http 本来就是个应用层协议,也不会换个网卡就不能用。撑也
没有这么撑的,你不服从驱动到 TCP实现了再来。我不说了,你这思路就是错了,一个
堆机器就能解决的问题,要等别人的研究成果。要是研究不出来,你就不做了?
T********i
发帖数: 2416
39
来自主题: Programming版 - 10M persistent TCP connections
看来你是真的蠢。Client和Server到底哪个需要CPU处理时间长取决于具体应用。
"client就是往外发,啥都不管。server可是要处理的。"这种无脑的话都能说出来?
再说了,我们讨论的C10M是网络处理问题。要尽量和应用层分开。
即使讨论whatsapp,C10M用于前端,App逻辑也很简单。
你这人脑袋简直一团浆糊。
g*****g
发帖数: 34805
40
来自主题: Programming版 - 10M persistent TCP connections
你丫除了死撑还会别的?都像你说的这么简单,为嘛4个月了12306就写了个太监版的计
数器,
连监听端口都不敢。你要我写个模拟千万用户的12306 client,我一天以内保证写出来。
server端有数据库问题,有failover问题,要考虑的东西多了。
网络处理要尽量跟应用层分开是不错,偏偏你又要c10m, zero copy,应用想独立于
driver api都不行。
b********e
发帖数: 595
41
来自主题: Programming版 - 请教一个TCP连接的问题

客户端应该不会slow start了,当时这个参数的调整就是google对web服务器用来解决
slow start的。发文章的两位里有一位还是华裔呦。
http://www.ietf.org/proceedings/10mar/slides/iccrg-4.pdf
tcp fastopen什么的没有仔细学习,好像是这两年才支持的,一直没关注了,不知道是
不是面试官希望的答案。
http://research.google.com/pubs/author39277.html
我不确认面试问的具体是tcp还是应用层面的问题,如果面的是应用的dev一般不改问这
么底层的东西。
应用层面应该goodbug 更有经验。
o******0
发帖数: 105
42
新人都学java了。而且应用层的东西不停得变,你得不停得学。
z****e
发帖数: 54598
43
应用层的东西是不停地加,不是不停地变
你总有新的东西可以获取,然后增加经验
提升等级,以后打大怪
系统层的东西变化很慢,而且一直都没有新东西出来
看看微软的ie吧,垄断时候,裁员裁到剩下7个人
你有信心成为那7个人中的一个么?good luck
v***e
发帖数: 2108
44
你推崇的NoSql里面,三大Market leader里面MongoDB, Couchbase(memcahced)
是C++的,Cassandra是Java的, 2:1.
现在号称真正支持ACID, transaction的NoSQL, FoundationDB,
也全部是C++写的。
当然Java也是个不错的语言,容易上手,应用层用的多,工作机会多
但是在系统层,真正mission critical的东西,JAVA要想完全取代C++还差的远,
至少两者是并列的, 更不用说Java也有自己的问题。
你对C++的仇恨是哪里来的? totally nonsense
f********t
发帖数: 6999
45
【 以下文字转载自 JobHunting 讨论区 】
发信人: ocean100 (ocean100), 信区: JobHunting
标 题: C++虽然工作机会少一些,但没有新毕业生和你抢饭碗
发信站: BBS 未名空间站 (Wed Mar 12 22:53:50 2014, 美东)
新人都学java了。而且应用层的东西不停得变,你得不停得学。
M*****n
发帖数: 2301
46
来自主题: Programming版 - 这个班就被zhaoce这种搞臭了
看看it得最近的帖子,基本上半瓶子水,除了堆砌名词之外没有任何本事,
糊弄半路出家新毕业的可能还行,真正有点经验的一看这就是一个joke啊
打滚刷屏倒是挺在行的,用java写点应用层的东西,就来宣布C++死刑了,
也不照照镜子,袋鼠国真是出人才。
人说java程序员门槛低,这个zhaoce真是最好的例子。
M*****n
发帖数: 2301
47
来自主题: Programming版 - 招人过程中关于语言一点小经验
人家问我是不是没碰上某java程序员,我说我们对netflix这种
应用层的一般不感兴趣,因为需求不同,这很难理解?
至于赚多少钱,我有一个字涉及赚多少钱么?如果你非要用钱衡量,你怎么知道我们
没netflix挣钱多,你说的和我说的没有半点关系。


T*****e
发帖数: 361
48
来自主题: Programming版 - 招人过程中关于语言一点小经验
个人感觉你说的很在理,的确你们可能对做应用层的人不是很感兴趣。我觉得cxq可能
觉得你的语气很让人疑惑,包括“这种……的人”以及后面关于造车开车的类比,字里
行间透着些不屑(也许我有点敏感,大概你并非有意吧)。
在美国呆了几年,感触比较深的一点就是大家交流方式的差别。我们(大陆出身的)华
人说话更加直接一些,一是一二是二,很多时候没有为对方考虑,没有想过这话对方是
不是会难以接受。美国人大多委婉一些,直接拒绝或者贬低别人(包括观点)的时候少
。如果我们在讨论的时候稍微注意点对方的感受,我想吵架的时候会少很多。
就像魏老师和好虫,本来好好的讨论技术问题,两个人的方案虽然差别很大,但双方也
都有独到的理解,最后却闹得不可开交,互相揪小辫甚至人身攻击,很是可惜!
——没有指责你的意思,只是想提醒下,大家经验以及视角不同,看到的东西可能会有
差异。一般情况下还是先夸一句然后转折更容易让人接受一些。仔细说起来我也没资格
说这话,我自己也做不好。共勉吧!
g*****g
发帖数: 34805
49
来自主题: Programming版 - 招人过程中关于语言一点小经验
我干的活你干不来,你干的活我干不来。其实都很正常,术业有专攻,啥东西都需要经
验才能深入。
至于看不起这个看不起那个就不必了,应用层的水同样很深。做什么更多是个选择,
Datastax也来骚扰过我。Java就是工作机会多一些
,我常说的就是这个。

nosql)
M*****n
发帖数: 2301
50
来自主题: Programming版 - 招人过程中关于语言一点小经验
这位id说的在理,好吧,我承认我语气可能会造成误解。
其实我并没有任何看不起应用层Java程序员的意思,我前面也说了
曾经interview过很好的Sun出来的Java程序员。Java也是很好的
语言,这个毋庸置疑,我自己也用Java写东西。C++和Java各有千秋,
优劣比较不是一句“C++要死了”能解释的。
说老实话,这个版的那么几个Java程序员实在是令人生厌,自己半瓶子水,
对语言,对系统看不出有什么深刻了解,还自以为是,成天误导新手id,
要么就打滚刷屏骂大街,劣币驱逐良币,好好一个班弄成这样,
挺烦人的。
其实我从来不参与这里的吵架,只是今天看到那个澳大利亚Java程序员
实在是太离谱才忍不住说两句。
首页 上页 1 2 3 4 5 6 7 8 下页 末页 (共8页)