x****u
发帖数: 44466 | 1 汇编当然算语言，宏语法很重要，你敲几天机器码后就明白了。 |
|
x****u
发帖数: 44466 | 2 没宏指令，你地址都是敲的数字么？
当年苹果2下汇编程序就两种写法，一种是通用的，即机器码poke进去，另一种是高级
的，指令名是英文，地址和操作数都是数字。 |
|
|
s********i
发帖数: 17328 | 4 不知道这个争论的意义是什么？不可替代就是个伪命题。我还可以说机器码不可替代，
指令集不可替代。上面的那个例子，coding/encoding是c/c++，而所有以上的应用都是
java，你觉得你会做那一样？各个领域都有存在的必然性，但并不表示有前途。c/c++
等at the most是个stable if not shrinking，而java等at the least是growing if
not booming。 |
|
x****u
发帖数: 44466 | 5 Lisp放入内核态，整个堆栈，虚拟内存机制全都完蛋，放入CPU，流水线，分支预测等
等全都要完蛋。
至于编译质量低下还真不是大问题，现在的编译器前端只管翻译到中间代码，优化，机
器码生成和机器码优化都是统一的。
么? |
|
|
z****e
发帖数: 54598 | 7 最早有了c，c之前就不说了
c占领了市场，后来有了c++
但是c++基本上被证明是错误的
大多数程序猿看不懂
所以后面才有了java，java是第一个算是成功替换c++的语言
当然也遇到了问题，就是一开始比较慢
10年前跑一个java代码跟今天跑一个java代码，不是一回事
有了ibm,sun,oracle甚至包括m$的持续投入
才有了今天jvm的效率，将来就靠amazon和linkedin这些了
然后是php，针对web做简化，php也取得巨大的成功
现在你还在用php上买买提就是明证
然后fb现在在针对php做优化，hiphop把php先转译成c++
然后再编译成机器码执行，但是垮平台成了主要问题
最初版本只能在centos和fedora上运行
但是不管怎样，这是一个比较好的优化，也是切实可行的优化
这个产品的出现，对于php社区是一个最好的促进
然后才是google的javascript，js在ui上的流行
促使很多人投入，其中就包括google自身
然后有了v8和coffeescript这些，但是google在这之前
也遇到了c++代码很难维护的问题，当时的解决方案是通过pyt... 阅读全帖 |
|
z****e
发帖数: 54598 | 8 最早有了c，c之前就不说了
c占领了市场，后来有了c++
但是c++基本上被证明是错误的
大多数程序猿看不懂
所以后面才有了java，java是第一个算是成功替换c++的语言
当然也遇到了问题，就是一开始比较慢
10年前跑一个java代码跟今天跑一个java代码，不是一回事
有了ibm,sun,oracle甚至包括m$的持续投入
才有了今天jvm的效率，将来就靠amazon和linkedin这些了
然后是php，针对web做简化，php也取得巨大的成功
现在你还在用php上买买提就是明证
然后fb现在在针对php做优化，hiphop把php先转译成c++
然后再编译成机器码执行，但是垮平台成了主要问题
最初版本只能在centos和fedora上运行
但是不管怎样，这是一个比较好的优化，也是切实可行的优化
这个产品的出现，对于php社区是一个最好的促进
然后才是google的javascript，js在ui上的流行
促使很多人投入，其中就包括google自身
然后有了v8和coffeescript这些，但是google在这之前
也遇到了c++代码很难维护的问题，当时的解决方案是通过pyt... 阅读全帖 |
|
|
d****i
发帖数: 4809 | 10 嵌入系统和底层不能用OO的主要原因是：
1. C++比C还是有些overhead
2. C++的编译器很难优化
3. C更接近机器码指令集
4. 底层的东西完全是bare metal的光膀子裸干，就是需要像C这样的猛汉利刃单刀直入
和硬件talk，而不是C++的这种OO的犹抱琵琶半遮面。 |
|
g*****g
发帖数: 34805 | 11 是没那么重要，你那单机就算拿机器码写也撑不住。 |
|
S*A
发帖数: 7142 | 12 声明一下，只是小混混，不是大牛。
ObjC 我觉得是超级优美而且效率又高的语言。
ObjC 和 C 完全兼容，无缝链接。C++和 C99是不可能
能完全兼容的。我隐约记得 template 和 C99 的结构上
的是无法融合的。
ObjC 的 interface 要比 C++ 的多重继承优美很多而且
灵活很多。整个语言也要比 C++简单很多，C++ 的 template
过于复杂。ObjC 的 OO 更接近 Small Talk。
ObjC 的语言本身是多平台的， gcc-objc Linux 也有，
而且 Linux 上面也有 GNUStep 这样的东西。
ObjC 不能很好推广，其中主要一个原因在与库。因为
只有 Apple 一家用，所以语言本身的标准库界定不明显。
很多 Apple 的库在其他 OS 上面运行不起来，给这个语言的
移植性造成了一定困难。单单是语言本身，移植性是非常好
的，基本上和 C 一样，关于 Obj 基本上没有什么变化。
特别是 Clang 以后，很多平台都可以跑。
ObjC 的 Object Call 实现是非常精妙的，用很少的代价和
性能（机器码的数量和复... 阅读全帖 |
|
d****i
发帖数: 4809 | 13 什么叫"C++的问题就是它永远不native"，C++不是和C一样生成机器码? |
|
n****1
发帖数: 1136 | 14 我越来越觉得js像web assembly lang, 就跟x86机器码样的. 的确是广泛支持,但不值
得用手写. |
|
|
z*******h
发帖数: 346 | 16 俺当年直接输入Z80机器码，单板机只有电话那样的数字键盘。
8051 |
|
s****u
发帖数: 1433 | 17 呵呵，查询就是了？
你随便写个查询程序，编译成机器码，看看
有多少行嘛。 |
|
S*A
发帖数: 7142 | 18 公平性是比较好的保证了，如果有票没有出，是不会停止循环的。
而且落到同一 core 的是有严格先后次序的。
如果是不同 core之间，其实没法严格 measure 并发的时候的次序。
所以 memory update 次序是最接近的了。
开销肯定不是加倍，用这个实验的数据测量应该是没有很大区别。
不信可以试试，看看是不是速度减半，我打赌肯定不是。
好在这个测试我们是可以自己做的，不用牛B网卡和机器。
补充一下，不是加倍是因为那个 automic update 和程序其他的
开销来说是完全忽略不记的。到了机器码这一层我还是比较有信心
的。好在这个实验可以验证，补丁和没有补丁的性能。 |
|
d****i
发帖数: 4809 | 19 以前一些老的C compiler，用指针access element确实比用index快，所以经常有*p++
= *q--这样的convention，后来的编译器把a[i]优化得和*(a+i)生成的机器码完全一摸
一样了。 |
|
e***e
发帖数: 3872 | 20 能抄来凑出正确答案就行，if不会又有什么关系？
atoi这种路子是武当少林的气宗（现在的牛人当然还是这宗出来的，记得Knuth讲起自
己的code来，那个亲密流畅……），但最后笑傲江湖的是剑宗（是，现在要会找，会抄
，会拼凑还是要先练吐納）和变态：机器码农——我理解的葵花宝典。 |
|
|
n*w
发帖数: 3393 | 22 .net native好像编译成机器码? xiamian是不是早这样了？ |
|
x****u
发帖数: 44466 | 23 最大的特性不是编译成机器码，这个JIT 10年前就搞定了，而是提取Framework搞静态
链接。静态链接是非常疯狂且愚蠢的想法。 |
|
|
d****i
发帖数: 4809 | 25 有道理, 在系统层写C的要把自己的code一边写一边变成对应的机器码指令。 |
|
|
d****i
发帖数: 4809 | 27 这个不是C++的问题，C里面就必须加#ifdef的防止，C++只不过继承了C的而已。至于为
什么要加这个防止，你仔细想想生成的每个模块的机器码就知道了 |
|
d****i
发帖数: 4809 | 28 这个不对吧，C里面没有操作符重载一说，数组的[]就是简单的指针操作，但是上述C++
里面的inline的操作符重载[]是一次函数调用，就会有点overhead，所以即便把中间的
require()去掉，还是比C稍有点performance hit。这个比较一下C和上面的C++生成的
机器码就知道了。 |
|
N******K
发帖数: 10202 | 29 我看过机器码 operator[] 这个函数优化之后 和 直接写 Array[index] 一样
++ |
|
d****i
发帖数: 4809 | 30 我就知道这种帖子很容易变歪，其实C++和Java的最大区别就是，C++是native语言，编
译成机器码，Java是VM语言，编译成bytecode。根据不同的具体应用情况来选择合适的
语言。两个语言语法非常相像，Java从C++简化而来，主要的区别不在于语法，而在于
两个语言有着不同的应用领域，从而有着相对应的库和生态系统。 |
|
S*A
发帖数: 7142 | 31 lisp 和 haskell 一样，要写出高效率的
代码需要很高的功力，那种高效的做法
往往是不直观简单的。实际的机器不是
那么clean，现在lisp就算编译还是不如c。
因为距离机器码比较远。 |
|
d****i
发帖数: 4809 | 32 C跟机器码指令集有着一一对应的关系，所以效率最高速度最快, 而lisp完全不同，想
用FP这种上层的逻辑来talk to底层的硬件，做梦。 |
|
z****e
发帖数: 54598 | 33 有一个项目叫做javafx ports
http://javafxports.org/page/home
idea也很简单，因为java已经实现了电脑上的跨平台
javafx是java的一部分，自然也实现了电脑上的跨平台
以及native compiling，可以直接编译成os(win,mac,linux)相关的机器码
那么现在这个项目要做的就是
把javafx给export到android和ios上去
ios靠的是robovm，很早以前就在做的一个通过java写ios上app的东西
android的话，因为dalvik本身支持jar的依赖
所以只要额外再打个包就好了
核心那个逻辑jar不用变，那个jar多半是javafx写的
客户端跨平台是一个美好的梦想
构想很好，操作起来，异常恶心
比如最简单的io，mobile和pc上的输入是不一样的，输出当然也不一样
各种屏幕，还有一些常用的第三方类库，比如卖广告的admob
admob不支持在电脑app上卖广告
所以到最后你还不如不跨平台
但是不管怎样，这种东西有总比没有好，有选择总是好滴 |
|
S*A
发帖数: 7142 | 34
别逗了。C type 是直接对应机器代码的 type 的。
C 直接生成机器码，中间没有什么另外的翻译。
C 可以直接嵌入汇编代码，你的 FP 可以吗？
C 可以直接管理汇编代码里面的地址，就是指针。
基本上没有比 C 更加接近汇编的高级语言了。
FP 没有指针的话很多底层的东西都没法直接干。
实际上没有免费的午餐。C 就是实践中证明更合理的了。
C 语言本身也在发展。到现在 C 已经很成熟了。 |
|
W***o
发帖数: 6519 | 35 C的位置还挺高，呵呵
直接读写机器码的算root 了 |
|
z****e
发帖数: 54598 | 36 那不好说
io都是个问题的话
你这个实践起来会有巨大的障碍
你见过哪个oop连io都搞不定的？
io最简单就是搭配上一个变量
fp一看就难受，浑身难受，不纯了嘛
但是又没办法，就各种纠结
还有扁平化的问题，这个随着rxjava的出现
fp会越来越突出，因为那一坨括号金字塔的确是很让人讨厌呀
可读性就这么被弄低的，偏偏oop那边这个搞定了，因为本来也没有多少这个问题
加上一开始为了异步效率而导入的fp也被rxjava搞定，连效率提升这个初衷也都没有了
自然就让人没有理由坚持下去了嘛
就我实践中看，oop为主，fp为辅是绝佳的，没有什么不对
效果良好，倒是你的工具scala不少人说看不懂
可行和执行效果是两回事，我并没有在说可行不可行
理论上啥不可行，你自己刻机器码都可行不是？ |
|
h******n
发帖数: 3599 | 37 【 以下文字转载自 Military 讨论区 】
发信人: hutuxian (糊涂仙), 信区: Military
标 题: 说某种语言是解释性语言的全是文科生
发信站: BBS 未名空间站 (Sat Mar 7 17:46:44 2015, 美东)
如果说， 某种语言的某个具体实现implementation 是解释性的, 可以这么说,
bytecode steam更加类似.net 和 java这种通用虚拟机器码的， 比高级解释语言效率高
， 比native compiled language不如 |
|
T********i
发帖数: 2416 | 38 看是什么事情，一般node也就是把数据从一个地方搬运到另外一个地方。基本只处理异
步I/O。这种情况下动几步就进入native C/C++实现的函数里面去了。当然速度快了。
另外，Google V8是基于C++，没C++ node玩不转。
V8是JIT。也就是能编译成机器码再运行。即使如此，这种dynamic typed JIT性能肯定
不如JVM。其实，同样是dynamic typed，V8都不一定干得过LuaJIT。
其实我个人更喜欢Lua多一些。Lua可能是最简单的语言了。我觉得任何人都很难会不喜
欢Lua。 |
|
m*******e
发帖数: 1598 | 39 有几个能自己写机器码的
有几个能自己设计处理器的
有几个能自己设计电路的
有几个能自己提纯硅的
...
有几个能自己生火的
缺一条都不算全栈码工 |
|
h*i
发帖数: 3446 | 40 现实。
这其实是个机器执行性能和人的生产力的矛盾，平衡点在哪里要看用例，这是一个CTO
技术眼光的问题。
haskell这些编译成优化的机器码的当然性能不错，但生态环境要差点。Clojure直接用
Java的生态环境，出东西快，而且稍微费点功夫去优化代码（比如用array而不用seq,
用unchecked math, 用type hint，等等），也可以做到和Java一样的性能。
关键就看值不值得去优化。一般Web应用，瓶颈在网络，所以大家用Clojure不怎么优化
也觉得就够了。有的应用，比如数值分析，那Java也不行，还得调用原生的Fortran库
，这个Clojure也能作。
总之Clojure的哲学是让方便的东西方便，简单的东西简单，需要优化的地方可能优化
，尽量把语言本身带来的复杂性去掉，留下问题本身的复杂性让人来解决。 |
|
q*c
发帖数: 9453 | 41 人家是全球黑客排名第七，美帝海军无法 debug 时找去 debug 的人。 因为那项目过
于机密，结果他们只能通过电话 debug, 呵呵，就是对面的人给他们念机器码。 就这
样人还是把问题找到了。
随便找一段二进制， 结果读了大概 1 分钟， 那家伙说， 这大概是 string 里面的
indexof 还是什么函数， 结果把 symbol load 进去一看， 还真是。 我当时觉得这些
世界闻名的黑客还是有点真本事。
大牛是看菜下饭不错，不过不说明大牛就对菜的好坏没看法了。 大牛就是见的多，所
以看法更全面。 |
|
h*i
发帖数: 3446 | 42 怎么不一样？我们都看到了，用的时候代码是一样的，那还能有什么不一样？
只能是用到的资源不一样，效率不同。
现在我看了core.async的实现细节（见下面的video)，我甚至认为连效率可能都差不多
。core.async的go是一个宏，在编译前就变成了state machine, 没有runtime
overhead, 而且这个state machine是用mutable state实现的，最后编译成jump table
机器码。我相信Go语言的实现也不会比这效率高到哪去。
https://www.youtube.com/watch?v=R3PZMIwXN_g&t=24m46s |
|
e***i
发帖数: 231 | 43 最多Java能把C++编译到JVM上，难道还能编译成native汇编和机器码不成？ |
|
n*****t
发帖数: 22014 | 44 就按机器码死往 exe 里写呗，理论上可以，实际上脑子进水了。每种语言都有特定适
合的地方，比如你非要跟荷兰人说桑海话，也不是肯定听不懂，但绝对让门夹了。
尼玛，又歪到咖啡西加加了。 |
|
q*c
发帖数: 9453 | 45 你程序写多了，世界成了 2 进制了，要显式， 就必须机器码，不然就必须隐式到底。
是这样吧？
hardware |
|
w***g
发帖数: 5958 | 46 编译成机器码的语言，要么你就别学。如果真要学，
第一件事情是把C++学好。至于要不要机器吗，还是
字节码就足够好了这个另说。 |
|
w***g
发帖数: 5958 | 47 编译成机器码的语言，要么你就别学。如果真要学，
第一件事情是把C++学好。至于要不要机器吗，还是
字节码就足够好了这个另说。 |
|
|
l*******m
发帖数: 1096 | 49 就是LLVM IR的东东。一般人不会用到它。但是对model serving, 嵌入式系统, 新的
加速器后端回有帮助。
update: 刚才试试XLA，没有成功。从错误信息上看。在运行TF时，先把TF GRAPH转化
成XLA GRAPH，然后针对所运行的图做JIT产生机器码。好了，他们的代码刚CHECK IN而
且没例子，我先不当小白鼠了。不过我感觉会对训练也有帮助如果能convert到XLA
GRAPH。 |
|
|
