entry level analog电路设计工程师# EE - 电子工程x*n2013-05-27 07:051 楼请问下如果有美国有效的f1 visa, 回国经日本停72小时内想出机场可以申transitvisa吧,看过几篇文章好象说72小时内要申shore visa,但有些风险,所以请教下有经验的各位大侠,还有想请问下能寄签吗,谢谢
R*g2013-05-27 07:055 楼 诸葛亮临终前,对于个人的后事没有多少,多是关于蜀汉的人事安排,对于政治方面的接班人,我们都知道,诸葛亮指定的是蒋婉、费祎,事实上还有董允,这四人被称为蜀汉四相。而军事上的接班人,诸葛亮似乎没有指定,一般的观点认为诸葛亮最在意的是姜维和杨仪,而不是魏延,因为诸葛亮一直担心魏延会造反,所以,诸葛亮去世时设计杀死了魏延,以绝蜀汉后患。而事实证明,真正有造反想法的却是杨仪。当然,诸葛亮是否有没有把军事大权传给魏延的想法一直有争议。其实,仔细阅读《诸葛亮传》,我们不难发现,无论魏延也好。杨仪也罢,还是后来真正挑起蜀汉军事大权的姜维,他们都不是诸葛亮最中意的军事接班人,诸葛亮真正最想把军事大权交给另一个人,这个人大家或许想象不到,因为无论在《三国志》还是在《三国演义》中似乎都没有多少涉及,大家熟知的应该是出现在诸葛亮的《出师表》中,这个人是谁呢?他就是将军向宠。大家知道,诸葛亮在北伐中原前,向后主刘禅上书了《出师表》,在一千多年之后,我们再次品读《出师表》,没有谁不为诸葛亮对蜀汉的忠心所感动的,这或许才是诸葛亮一直为后人所传颂的根本原因。诸葛亮的《出师表》,主要表达了五个方面的意思,一是诸葛亮表达了自己对蜀汉的忠心,那是苍天可鉴,日月可昭;二是表达了对国家未来的担心,并表达了对国家统一大业的强烈愿望;三是希望后主刘禅振作起来,为国家的前途着想;四是表达此次北伐中原无所畏惧,慷慨赴死之决心;五是向后主刘禅推荐了一批未来可重用之才,自己如果有不测,后主刘禅重用他们,可保国家安虞,这实际上就是诸葛亮为了防备自己如果不测的后事安排。所以,《出师表》的重点其实是诸葛亮北伐后对国家的人事安排。从《出师表》中我们可以了解到,诸葛亮提到了几个人,这其中有郭攸之、费祎、董允、向宠四人,其中郭攸之、费祎、董允是文官,除郭攸之后来不知所踪之外,费祎、董允都是未来的治国之才,事实上也是蜀汉未来的栋梁,而向宠,是诸葛亮提到的唯一一个军事将领,对他的评价是: 将军向宠,性行淑均,晓畅军事,试用于昔日,先帝称之曰 “能 ”,是以众议举宠为督。愚以为营中之事,悉以咨之,必能使行阵和睦,优劣得所。这诸葛亮对向宠的评价来看主要有五个方面:一是向宠军事方面很不错;二是向宠是经过多次考验的;三是向宠是先帝刘备认可的,也是大家都认可的;四是向宠能够团结大家,治军有方,懂得什么是好,什么是坏;五是向宠对国家绝对忠心。对于向宠的评价,或许是诸葛亮一生中对其他人的最高评价,在诸葛亮的眼中,蜀汉政权里或许没有人超越他,字里行间我们不难读出,诸葛亮对于自己之后蜀汉的军事领导者安排已经有了着落,非向宠莫属。那么,向宠为何人呢?知道他的人似乎并不多,事实上向宠也是名门之后,他是蜀汉重臣向朗兄弟的儿子,在公元 222 年,刘备东征伐吴发动夷陵战役时,向宠作为刘备手下门牙将一路东征,虽然刘备在夷陵战役中是大败,各营都损失惨重,但唯独向宠领导的军营完好无损,因此获得刘备的高度重视,诸葛亮《出师表》中说他得到先帝的称赞和试用,其实就是根据向宠在夷陵之战中的表现,刘禅即位后,在诸葛亮的举荐之下,被封为都亭侯,负责管理宫廷宿卫军,实际上就是卫戍部队司令。公元 227 年,诸葛亮北上汉中,在后来的北伐中,向宠被任命为中领军,可见,诸葛亮一直将向宠作为未来军事首领在培养。然而,历史之谜就在诸葛亮北伐中原之后再次发生,作为诸葛亮一直作为未来军事继任者培养的向宠,竟然在公元 234 年,诸葛亮病逝五丈原之后没有了消息,只有魏延、杨仪在为军事指挥权而争斗,而斗争的结果是魏延被杀,杨仪被贬,姜维最终取得军事指挥权,而蒋婉、费祎、董允相继取得政治大权,作为诸葛亮军事方面的继承者向宠似乎没有了消息。因为蜀汉不置史,所以,为什么向宠最终没有成为诸葛亮的军事继承者,这里面肯定有我们不为人知的秘密。至于秘密如何,或许永远不会有人知道,其实,关于魏延被杀是否真是诸葛亮生前所谋划那也是历史之谜,从向宠最终没有成为诸葛亮军事继承人来看,我们有足够的理由怀疑是不是有人篡改了诸葛亮的临终意愿。三国中为什么蜀汉有那么多历史之谜,表面上是因为蜀汉不置史,实际上是蜀汉这个国家实在太传奇,传奇到什么都是国家秘密,秘密到一个国家竟然不敢置史。但是,关于向宠的事迹依然没有结束,公元 240 年, 汉嘉地区蛮夷发生叛乱,向宠率军前往平定,在混战中身亡。由于向宠平时深得部下人心,所以在向宠的属下得知向宠被害后,返兵奋力冲杀,终于把向宠的遗体夺回,送回成都安葬,从这件事可以看出,向宠在军事上的影响有多大,深受部属爱戴到何种程度,从而也表现了向宠不为职务的升迁所影响,一心爱国,最终战死沙场,从而证明了诸葛亮对向宠的评价完全是正确的,至于向宠能够夷陵战役不死,北伐战役不死,却死在平叛内乱中,或许又是一个永远的历史之谜,真是一个神奇的国度。但是,虽然诸葛亮之后,向宠虽然最终没有成为诸葛亮军事方面的继承者,但诸葛亮最中意向宠,意在培养向宠为自己军事方面的继任者这一点似乎不能否认。
q*y2013-05-27 07:056 楼尤其是在那种成千上万个cluster上跑的。如果是,为什么不把Java程序编译成nativebinary,直接以native process 在 server端跑。这样不是快很多吗?问题可能比较傻,请见谅!
z*z2013-05-27 07:058 楼代朋友发贴:在加州硅谷地区的创业型公司,招entry level 模拟电路设计工程师,主要设计项目包括,voltage/current reference, charge-pump, amplifier, comparator, latch, power design。有0-2年相关经历。有兴趣的,可以通过[email protected]com 联系
D*a2013-05-27 07:059 楼leveraged ETF will go to zero by design. It is not for overnight holdinganyways.【在 q****x 的大作中提到】: FAZ最高10k,现在27,不到千分之三,可以说已经清零。: 五年时间,多少青蛙前赴后继。
t*a2013-05-27 07:0511 楼都是在jvm上运行早先的java版本是把byte code给jvm解释执行现在是用JIT(just in time compiler) 边load边编译成native code直接给processor执行所以java class load是很慢的,但是执行起来的速度还是很快的native【在 q********y 的大作中提到】: 尤其是在那种成千上万个cluster上跑的。如果是,为什么不把Java程序编译成native: binary,直接以native process 在 server端跑。这样不是快很多吗?问题可能比较傻: ,请见谅!
q*y2013-05-27 07:0514 楼谢谢你的回答。如果Java程序不是那种在cloud上跑的应用,而是本身就是提供infrastructure的,如那些个Hadoop,Cassandra什么的,为什么不把他们一次性编译成native code?processor【在 t***a 的大作中提到】: 都是在jvm上运行: 早先的java版本是把byte code给jvm解释执行: 现在是用JIT(just in time compiler) 边load边编译成native code直接给processor: 执行: 所以java class load是很慢的,但是执行起来的速度还是很快的: : native
z*e2013-05-27 07:0517 楼你可以一次性编译成native code啊这个可以借助第三方工具实现但是多数时候没有必要因为这样就跟os绑定了可能会发生一些特定os上才发生的bugs当然绝大多数时候也不会发生我觉得你完全可以这么做,没有太大问题另外一个就是java诞生之初就对客户做了一个承诺那就是compile once, run everywhere如果编译成native code的话,就违背了这个承诺所以大多数时候不提倡这么操作但是你完全可以这么做,也可以做到,不是很难的事【在 q********y 的大作中提到】: 谢谢你的回答。: 如果Java程序不是那种在cloud上跑的应用,而是本身就是提供infrastructure的,如: 那些个: Hadoop,Cassandra什么的,为什么不把他们一次性编译成native code?: : processor
c*n2013-05-27 07:0518 楼别说5,6年前, 15,16年前大学生毕业工资都有上千, 现在主要也是这个范围吧【在 c****6 的大作中提到】: 真的假的?: 5,6年前就这个价位。现在物价可涨了不少。
s*82013-05-27 07:0519 楼not at all. It did quadruple in 2008 within one month. It can wipe out yourmoney easily.【在 g*****g 的大作中提到】: 那short不是稳赢了。
t*a2013-05-27 07:0520 楼用jit这种dynamic的编译方法,有如下好处1,根据不同cpu,heap大小可以生成不同的native code2, 可以根据用户如何使用code来优化编译,而不是只通过分析code本身3,class的load和unload尽在掌握,随时可以重新编译以前玩gentoo的时候,动不动就重新编译一天,这种事在java世界就不会有了。。。。【在 q********y 的大作中提到】: 谢谢你的回答。: 如果Java程序不是那种在cloud上跑的应用,而是本身就是提供infrastructure的,如: 那些个: Hadoop,Cassandra什么的,为什么不把他们一次性编译成native code?: : processor
t*a2013-05-27 07:0522 楼java不是这么玩的。。。。虽然总有人想这么干【在 z****e 的大作中提到】: 你可以一次性编译成native code啊: 这个可以借助第三方工具实现: 但是多数时候没有必要: 因为这样就跟os绑定了: 可能会发生一些特定os上才发生的bugs: 当然绝大多数时候也不会发生: 我觉得你完全可以这么做,没有太大问题: 另外一个就是java诞生之初就对客户做了一个承诺: 那就是compile once, run everywhere: 如果编译成native code的话,就违背了这个承诺
q*y2013-05-27 07:0524 楼但是像Java 的 bigdata 一大类应用如Hadoop实际也都是在linux cluster上跑吧。也就是事实上跟os绑定了。而且作为公司来说,也不在意这种os绑定,又不是终端消费者,变来变去的。对提供infrastructure服务的一大票如Cassandra等为什么没有必要啊?对客户的承诺 “compile once, run everywhere”主要是针对front end 和Applicationdevelopper 的吧? 作为backend infrastructure,就像你常说的,各个大公司都是定制的,什么“os绑定”,“compile once, run everywhere”应该没人在意吧?【在 z****e 的大作中提到】: 你可以一次性编译成native code啊: 这个可以借助第三方工具实现: 但是多数时候没有必要: 因为这样就跟os绑定了: 可能会发生一些特定os上才发生的bugs: 当然绝大多数时候也不会发生: 我觉得你完全可以这么做,没有太大问题: 另外一个就是java诞生之初就对客户做了一个承诺: 那就是compile once, run everywhere: 如果编译成native code的话,就违背了这个承诺
q*y2013-05-27 07:0526 楼谢谢你告诉我这些东西。我怕再问下去就nagging了。【在 t***a 的大作中提到】: 用jit这种dynamic的编译方法,有如下好处: 1,根据不同cpu,heap大小可以生成不同的native code: 2, 可以根据用户如何使用code来优化编译,而不是只通过分析code本身: 3,class的load和unload尽在掌握,随时可以重新编译: 以前玩gentoo的时候,动不动就重新编译一天,这种事在java世界就不会有了。。。。
z*e2013-05-27 07:0527 楼任何java的产品,都能在windows和unix上跑所以说,cassandra和hadoop都可以在win/unix server上用但是这种要处理io,所以有些时候会出现一些特定的问题在不同的os上,但是理论上是完全可以用的hadoop的file system也就是hdfs还不够成熟,版本现在好像还在0.x所以正式版还没有出来,所以完全有可能遇到各种问题这就是现实世界,现在开源的big data还不很成熟还需要时间【在 q********y 的大作中提到】: 但是像Java 的 bigdata 一大类应用如Hadoop实际也都是在linux cluster上跑吧。也: 就是事实上跟os绑定了。而且作为公司来说,也不在意这种os绑定,又不是终端消费者: ,变来变去的。: 对提供infrastructure服务的一大票如Cassandra等为什么没有必要啊?: 对客户的承诺 “compile once, run everywhere”主要是针对front end 和: Application: developper 的吧? 作为backend infrastructure,就像你常说的,各个大公司都是定: 制的,: 什么“os绑定”,“compile once, run everywhere”应该没人在意吧?
z*e2013-05-27 07:0528 楼一般大公司不会定制jvm下的东西因为大公司下面一堆乱七八糟的操作系统大部分公司都有linux/windows/unix的os很多,开发机器现在还有macosx,所以不同平台上的兼容性是一个很大的问题比如我们开发一般都是macosx,测试用的是windows但是实际部署时候,生产环境用的是linux如果不用java,那就要每次都跑生产环境上去编译这样搞会挂,所以jvm是很重要的一个工具,没有jvm的话很多问题搞不定啊,pc上的os跟server上的os一般来说不一样compile once run everywhere其实对server side来说才是最重要的mobile和pc上其实现在jdk8.0以后的版本就初步有打算搞native compiling了javafx就有这个选择【在 q********y 的大作中提到】: 但是像Java 的 bigdata 一大类应用如Hadoop实际也都是在linux cluster上跑吧。也: 就是事实上跟os绑定了。而且作为公司来说,也不在意这种os绑定,又不是终端消费者: ,变来变去的。: 对提供infrastructure服务的一大票如Cassandra等为什么没有必要啊?: 对客户的承诺 “compile once, run everywhere”主要是针对front end 和: Application: developper 的吧? 作为backend infrastructure,就像你常说的,各个大公司都是定: 制的,: 什么“os绑定”,“compile once, run everywhere”应该没人在意吧?
t*a2013-05-27 07:0529 楼jit这东西还是没c++快。。。更别说c了可怎么办呢,就算一次性编译成native code减少的可能只是class load的时间, 这事水太深了,c++编译器都搞了这么多年了,这条路也不好走啊【在 q********y 的大作中提到】: 谢谢你告诉我这些东西。: 我怕再问下去就nagging了。
z*e2013-05-27 07:0530 楼各大公司一般不定制os,从jvm以下的部分都是直接买或者直接用现成的产品要么开源要么商用,现在做os的越来越少了就是jvm也越来越少有公司在做了定制的部分在jvm以上,其实企业端的定制部分会再往上一点jvm以上的app server都是产品,然后app server这个容器内的东西,才是真正定制的,其它都是类似的产品品牌不一样而已,ibm的叫websphere,oracle的叫weblogicred hat的叫jboss etc.web公司现在如果用java的big data产品的话从jvm以上开始定制,比如amazon和linkedin都用jvm,但是写的java code,那就不是一回事了大相迳庭了如果不用java的话,从os以上开始定制或者python或者ruby或者php或者tomcat etc.象google这种公司,则是干脆从底层自己搞但是没有多少公司能像google这么折腾的,google有钱有能人能做事其它公司找不到能写os的【在 q********y 的大作中提到】: 但是像Java 的 bigdata 一大类应用如Hadoop实际也都是在linux cluster上跑吧。也: 就是事实上跟os绑定了。而且作为公司来说,也不在意这种os绑定,又不是终端消费者: ,变来变去的。: 对提供infrastructure服务的一大票如Cassandra等为什么没有必要啊?: 对客户的承诺 “compile once, run everywhere”主要是针对front end 和: Application: developper 的吧? 作为backend infrastructure,就像你常说的,各个大公司都是定: 制的,: 什么“os绑定”,“compile once, run everywhere”应该没人在意吧?
g*g2013-05-27 07:0531 楼最重要的原因,大多数server应用的瓶颈并不在CPU上,你就算直接上C,throughput也不会更好。server应用最常见的瓶颈在DB IO上。而且JIT最多也就比C慢一倍。【在 q********y 的大作中提到】: 但是像Java 的 bigdata 一大类应用如Hadoop实际也都是在linux cluster上跑吧。也: 就是事实上跟os绑定了。而且作为公司来说,也不在意这种os绑定,又不是终端消费者: ,变来变去的。: 对提供infrastructure服务的一大票如Cassandra等为什么没有必要啊?: 对客户的承诺 “compile once, run everywhere”主要是针对front end 和: Application: developper 的吧? 作为backend infrastructure,就像你常说的,各个大公司都是定: 制的,: 什么“os绑定”,“compile once, run everywhere”应该没人在意吧?
c*e2013-05-27 07:0532 楼pre-JIT is not recommended in general. The client requests will warm up yourserver code very fast.
z*e2013-05-27 07:0533 楼在mobile和tablet上就没那么快了可能以后会有那么快,这个要靠小菊花和猴屁股们的努力了所以现阶段,client side的native compiling还是用比较大市场的your【在 c****e 的大作中提到】: pre-JIT is not recommended in general. The client requests will warm up your: server code very fast.
t*a2013-05-27 07:0534 楼server side那是没啥问题,至于客户端嘛,我这么多年做的都是不要求performance的。。。启动慢点就慢点,我记得java 1.4的时候,有客户抱怨,我们就让他启动的时候去倒杯咖啡。。。。your【在 c****e 的大作中提到】: pre-JIT is not recommended in general. The client requests will warm up your: server code very fast.
g*g2013-05-27 07:0535 楼Android上的应用,一点不慢。这个东西是要靠优化的,windows是M$的,Sun/Oracle想在Windows上优化,有难度。到Android上,底下的OS为了上面的VM该怎么改就怎么改,就可以做到。【在 z****e 的大作中提到】: 在mobile和tablet上就没那么快了: 可能以后会有那么快,这个要靠小菊花和猴屁股们的努力了: 所以现阶段,client side的native compiling还是用比较大市场的: : your
t*n2013-05-27 07:0536 楼android的慢是出了名的。类似的硬件,ios流畅的很。android 3/4搞了个硬件加速,就到处吹嘘。要是足够的快的,还搞什么加速?android就是移动os史一个笑话。每天用同样的硬件,要什么虚拟机?
z*e2013-05-27 07:0537 楼貌似google对android做了一定程度的优化但是下面的oem产商改了不少,水平达不到所以速度就跟不上了【在 g*****g 的大作中提到】: Android上的应用,一点不慢。这个东西是要靠优化的,windows是M$的,Sun/Oracle想: 在Windows上优化,有难度。到Android上,底下的OS为了上面的VM该怎么改就怎么改,: 就可以做到。
g*g2013-05-27 07:0538 楼LOL,移动史上的笑话秒了所有其他系统的总和。包括PC。【在 t*****n 的大作中提到】: android的慢是出了名的。类似的硬件,ios流畅的很。android 3/4搞了个硬件加速,: 就到处吹嘘。要是足够的快的,还搞什么加速?: android就是移动os史一个笑话。每天用同样的硬件,要什么虚拟机?
z*e2013-05-27 07:0539 楼这就是你跟google的差距google赌的是将来,拼的是明天十年前或者二十年前你同样可以说java在pc上很慢今天那就是另外一个故事了【在 t*****n 的大作中提到】: android的慢是出了名的。类似的硬件,ios流畅的很。android 3/4搞了个硬件加速,: 就到处吹嘘。要是足够的快的,还搞什么加速?: android就是移动os史一个笑话。每天用同样的硬件,要什么虚拟机?
g*g2013-05-27 07:0540 楼市场不是以小码农个人意志为转移的。要吗随波逐流,要吗被扒掉底裤。【在 z****e 的大作中提到】: 这就是你跟google的差距: google赌的是将来,拼的是明天: 十年前或者二十年前你同样可以说java在pc上很慢: 今天那就是另外一个故事了