Redian新闻
>
entry level analog电路设计工程师
avatar
entry level analog电路设计工程师# EE - 电子工程
x*n
1
请问下如果有美国有效的f1 visa, 回国经日本停72小时内想出机场可以申transit
visa吧,
看过几篇文章好象说72小时内要申shore visa,但有些风险,所以请教下有经验的各位大
侠,还有想请问下能寄签吗,谢谢
avatar
q*x
2
FAZ最高10k,现在27,不到千分之三,可以说已经清零。
五年时间,多少青蛙前赴后继。
avatar
f*o
3
谢谢!!!
avatar
R*g
5
诸葛亮临终前,对于个人的后事没有多少,多是关于蜀汉的人事安排,对于政治
方面的接班人,我们都知道,诸葛亮指定的是蒋婉、费祎,事实上还有董允,这四人被
称为蜀汉四相。而军事上的接班人,诸葛亮似乎没有指定,一般的观点认为诸葛亮最在
意的是姜维和杨仪,而不是魏延,因为诸葛亮一直担心魏延会造反,所以,诸葛亮去世
时设计杀死了魏延,以绝蜀汉后患。而事实证明,真正有造反想法的却是杨仪。当然,
诸葛亮是否有没有把军事大权传给魏延的想法一直有争议。
其实,仔细阅读《诸葛亮传》,我们不难发现,无论魏延也好。杨仪也罢,还是后
来真正挑起蜀汉军事大权的姜维,他们都不是诸葛亮最中意的军事接班人,诸葛亮真正
最想把军事大权交给另一个人,这个人大家或许想象不到,因为无论在《三国志》还是
在《三国演义》中似乎都没有多少涉及,大家熟知的应该是出现在诸葛亮的《出师表》
中,这个人是谁呢?他就是将军向宠。
大家知道,诸葛亮在北伐中原前,向后主刘禅上书了《出师表》,在一千多年之后
,我们再次品读《出师表》,没有谁不为诸葛亮对蜀汉的忠心所感动的,这或许才是诸
葛亮一直为后人所传颂的根本原因。诸葛亮的《出师表》,主要表达了五个方面的意思
,一是诸葛亮表达了自己对蜀汉的忠心,那是苍天可鉴,日月可昭;二是表达了对国家
未来的担心,并表达了对国家统一大业的强烈愿望;三是希望后主刘禅振作起来,为国
家的前途着想;四是表达此次北伐中原无所畏惧,慷慨赴死之决心;五是向后主刘禅推
荐了一批未来可重用之才,自己如果有不测,后主刘禅重用他们,可保国家安虞,这实
际上就是诸葛亮为了防备自己如果不测的后事安排。所以,《出师表》的重点其实是诸
葛亮北伐后对国家的人事安排。
从《出师表》中我们可以了解到,诸葛亮提到了几个人,这其中有郭攸之、费祎、
董允、向宠四人,其中郭攸之、费祎、董允是文官,除郭攸之后来不知所踪之外,费祎
、董允都是未来的治国之才,事实上也是蜀汉未来的栋梁,而向宠,是诸葛亮提到的唯
一一个军事将领,对他的评价是: 将军向宠,性行淑均,晓畅军事,试用于昔日,先
帝称之曰 “能 ”,是以众议举宠为督。愚以为营中之事,悉以咨之,必能使行阵和睦
,优劣得所。这诸葛亮对向宠的评价来看主要有五个方面:一是向宠军事方面很不错;
二是向宠是经过多次考验的;三是向宠是先帝刘备认可的,也是大家都认可的;四是向
宠能够团结大家,治军有方,懂得什么是好,什么是坏;五是向宠对国家绝对忠心。对
于向宠的评价,或许是诸葛亮一生中对其他人的最高评价,在诸葛亮的眼中,蜀汉政权
里或许没有人超越他,字里行间我们不难读出,诸葛亮对于自己之后蜀汉的军事领导者
安排已经有了着落,非向宠莫属。
那么,向宠为何人呢?知道他的人似乎并不多,事实上向宠也是名门之后,他是蜀
汉重臣向朗兄弟的儿子,在公元 222 年,刘备东征伐吴发动夷陵战役时,向宠作为刘
备手下门牙将一路东征,虽然刘备在夷陵战役中是大败,各营都损失惨重,但唯独向宠
领导的军营完好无损,因此获得刘备的高度重视,诸葛亮《出师表》中说他得到先帝的
称赞和试用,其实就是根据向宠在夷陵之战中的表现,刘禅即位后,在诸葛亮的举荐之
下,被封为都亭侯,负责管理宫廷宿卫军,实际上就是卫戍部队司令。公元 227 年,
诸葛亮北上汉中,在后来的北伐中,向宠被任命为中领军,可见,诸葛亮一直将向宠作
为未来军事首领在培养。
然而,历史之谜就在诸葛亮北伐中原之后再次发生,作为诸葛亮一直作为未来军事
继任者培养的向宠,竟然在公元 234 年,诸葛亮病逝五丈原之后没有了消息,只有魏
延、杨仪在为军事指挥权而争斗,而斗争的结果是魏延被杀,杨仪被贬,姜维最终取得
军事指挥权,而蒋婉、费祎、董允相继取得政治大权,作为诸葛亮军事方面的继承者向
宠似乎没有了消息。因为蜀汉不置史,所以,为什么向宠最终没有成为诸葛亮的军事继
承者,这里面肯定有我们不为人知的秘密。至于秘密如何,或许永远不会有人知道,其
实,关于魏延被杀是否真是诸葛亮生前所谋划那也是历史之谜,从向宠最终没有成为诸
葛亮军事继承人来看,我们有足够的理由怀疑是不是有人篡改了诸葛亮的临终意愿。三
国中为什么蜀汉有那么多历史之谜,表面上是因为蜀汉不置史,实际上是蜀汉这个国家
实在太传奇,传奇到什么都是国家秘密,秘密到一个国家竟然不敢置史。
但是,关于向宠的事迹依然没有结束,公元 240 年, 汉嘉地区蛮夷发生叛乱,向
宠率军前往平定,在混战中身亡。由于向宠平时深得部下人心,所以在向宠的属下得知
向宠被害后,返兵奋力冲杀,终于把向宠的遗体夺回,送回成都安葬,从这件事可以看
出,向宠在军事上的影响有多大,深受部属爱戴到何种程度,从而也表现了向宠不为职
务的升迁所影响,一心爱国,最终战死沙场,从而证明了诸葛亮对向宠的评价完全是正
确的,至于向宠能够夷陵战役不死,北伐战役不死,却死在平叛内乱中,或许又是一个
永远的历史之谜,真是一个神奇的国度。
但是,虽然诸葛亮之后,向宠虽然最终没有成为诸葛亮军事方面的继承者,但诸葛
亮最中意向宠,意在培养向宠为自己军事方面的继任者这一点似乎不能否认。
avatar
q*y
6
尤其是在那种成千上万个cluster上跑的。如果是,为什么不把Java程序编译成native
binary,直接以native process 在 server端跑。这样不是快很多吗?问题可能比较傻
,请见谅!
avatar
c*6
7
20万? 30 万?
avatar
z*z
8
代朋友发贴:在加州硅谷地区的创业型公司,招entry level 模拟电路设计工程师,主
要设计项目包括,voltage/current reference, charge-pump, amplifier, comparator
, latch, power design。有0-2年相关经历。有兴趣的,可以通过[email protected]
com 联系
avatar
D*a
9
leveraged ETF will go to zero by design. It is not for overnight holding
anyways.

【在 q****x 的大作中提到】
: FAZ最高10k,现在27,不到千分之三,可以说已经清零。
: 五年时间,多少青蛙前赴后继。

avatar
G*i
10
23
you can also go to united.com to make sure

【在 f********o 的大作中提到】
: 谢谢!!!
avatar
t*a
11
都是在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端跑。这样不是快很多吗?问题可能比较傻
: ,请见谅!

avatar
m*x
12
150K earth PHD
avatar
g*g
13
那short不是稳赢了。

【在 q****x 的大作中提到】
: FAZ最高10k,现在27,不到千分之三,可以说已经清零。
: 五年时间,多少青蛙前赴后继。

avatar
q*y
14
谢谢你的回答。
如果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

avatar
c*6
15
真的假的?
5,6年前就这个价位。现在物价可涨了不少。

【在 m****x 的大作中提到】
: 150K earth PHD
avatar
y*9
16
good point

【在 g*****g 的大作中提到】
: 那short不是稳赢了。
avatar
z*e
17
你可以一次性编译成native code啊
这个可以借助第三方工具实现
但是多数时候没有必要
因为这样就跟os绑定了
可能会发生一些特定os上才发生的bugs
当然绝大多数时候也不会发生
我觉得你完全可以这么做,没有太大问题
另外一个就是java诞生之初就对客户做了一个承诺
那就是compile once, run everywhere
如果编译成native code的话,就违背了这个承诺
所以大多数时候不提倡这么操作
但是你完全可以这么做,也可以做到,不是很难的事

【在 q********y 的大作中提到】
: 谢谢你的回答。
: 如果Java程序不是那种在cloud上跑的应用,而是本身就是提供infrastructure的,如
: 那些个
: Hadoop,Cassandra什么的,为什么不把他们一次性编译成native code?
:
: processor

avatar
c*n
18
别说5,6年前, 15,16年前大学生毕业工资都有上千, 现在主要也是这个范围吧

【在 c****6 的大作中提到】
: 真的假的?
: 5,6年前就这个价位。现在物价可涨了不少。

avatar
s*8
19
not at all. It did quadruple in 2008 within one month. It can wipe out your
money easily.

【在 g*****g 的大作中提到】
: 那short不是稳赢了。
avatar
t*a
20
用jit这种dynamic的编译方法,有如下好处
1,根据不同cpu,heap大小可以生成不同的native code
2, 可以根据用户如何使用code来优化编译,而不是只通过分析code本身
3,class的load和unload尽在掌握,随时可以重新编译
以前玩gentoo的时候,动不动就重新编译一天,这种事在java世界就不会有了。。。。

【在 q********y 的大作中提到】
: 谢谢你的回答。
: 如果Java程序不是那种在cloud上跑的应用,而是本身就是提供infrastructure的,如
: 那些个
: Hadoop,Cassandra什么的,为什么不把他们一次性编译成native code?
:
: processor

avatar
t*2
21
现在都是谁的收入长了那?

【在 c******n 的大作中提到】
: 别说5,6年前, 15,16年前大学生毕业工资都有上千, 现在主要也是这个范围吧
avatar
t*a
22
java不是这么玩的。。。。虽然总有人想这么干

【在 z****e 的大作中提到】
: 你可以一次性编译成native code啊
: 这个可以借助第三方工具实现
: 但是多数时候没有必要
: 因为这样就跟os绑定了
: 可能会发生一些特定os上才发生的bugs
: 当然绝大多数时候也不会发生
: 我觉得你完全可以这么做,没有太大问题
: 另外一个就是java诞生之初就对客户做了一个承诺
: 那就是compile once, run everywhere
: 如果编译成native code的话,就违背了这个承诺

avatar
S*I
23
公务员

【在 t*******2 的大作中提到】
: 现在都是谁的收入长了那?
avatar
q*y
24
但是像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****e 的大作中提到】
: 你可以一次性编译成native code啊
: 这个可以借助第三方工具实现
: 但是多数时候没有必要
: 因为这样就跟os绑定了
: 可能会发生一些特定os上才发生的bugs
: 当然绝大多数时候也不会发生
: 我觉得你完全可以这么做,没有太大问题
: 另外一个就是java诞生之初就对客户做了一个承诺
: 那就是compile once, run everywhere
: 如果编译成native code的话,就违背了这个承诺

avatar
T*T
25
领导 当权利益派

【在 t*******2 的大作中提到】
: 现在都是谁的收入长了那?
avatar
q*y
26
谢谢你告诉我这些东西。
我怕再问下去就nagging了。

【在 t***a 的大作中提到】
: 用jit这种dynamic的编译方法,有如下好处
: 1,根据不同cpu,heap大小可以生成不同的native code
: 2, 可以根据用户如何使用code来优化编译,而不是只通过分析code本身
: 3,class的load和unload尽在掌握,随时可以重新编译
: 以前玩gentoo的时候,动不动就重新编译一天,这种事在java世界就不会有了。。。。

avatar
z*e
27
任何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”应该没人在意吧?

avatar
z*e
28
一般大公司不会定制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”应该没人在意吧?

avatar
t*a
29
jit这东西还是没c++快。。。更别说c了
可怎么办呢,就算一次性编译成native code减少的可能只是class load的时间, 这事
水太深了,c++编译器都搞了这么多年了,这条路也不好走啊

【在 q********y 的大作中提到】
: 谢谢你告诉我这些东西。
: 我怕再问下去就nagging了。

avatar
z*e
30
各大公司一般不定制os,从jvm以下的部分
都是直接买或者直接用现成的产品
要么开源要么商用,现在做os的越来越少了
就是jvm也越来越少有公司在做了
定制的部分在jvm以上,其实企业端的定制部分会再往上一点
jvm以上的app server都是产品,然后app server这个容器内
的东西,才是真正定制的,其它都是类似的产品
品牌不一样而已,ibm的叫websphere,oracle的叫weblogic
red 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”应该没人在意吧?

avatar
g*g
31
最重要的原因,大多数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”应该没人在意吧?

avatar
c*e
32
pre-JIT is not recommended in general. The client requests will warm up your
server code very fast.
avatar
z*e
33
在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.

avatar
t*a
34
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.

avatar
g*g
35
Android上的应用,一点不慢。这个东西是要靠优化的,windows是M$的,Sun/Oracle想
在Windows上优化,有难度。到Android上,底下的OS为了上面的VM该怎么改就怎么改,
就可以做到。

【在 z****e 的大作中提到】
: 在mobile和tablet上就没那么快了
: 可能以后会有那么快,这个要靠小菊花和猴屁股们的努力了
: 所以现阶段,client side的native compiling还是用比较大市场的
:
: your

avatar
t*n
36
android的慢是出了名的。类似的硬件,ios流畅的很。android 3/4搞了个硬件加速,
就到处吹嘘。要是足够的快的,还搞什么加速?
android就是移动os史一个笑话。每天用同样的硬件,要什么虚拟机?
avatar
z*e
37
貌似google对android做了一定程度的优化
但是下面的oem产商改了不少,水平达不到
所以速度就跟不上了

【在 g*****g 的大作中提到】
: Android上的应用,一点不慢。这个东西是要靠优化的,windows是M$的,Sun/Oracle想
: 在Windows上优化,有难度。到Android上,底下的OS为了上面的VM该怎么改就怎么改,
: 就可以做到。

avatar
g*g
38
LOL,移动史上的笑话秒了所有其他系统的总和。包括PC。

【在 t*****n 的大作中提到】
: android的慢是出了名的。类似的硬件,ios流畅的很。android 3/4搞了个硬件加速,
: 就到处吹嘘。要是足够的快的,还搞什么加速?
: android就是移动os史一个笑话。每天用同样的硬件,要什么虚拟机?

avatar
z*e
39
这就是你跟google的差距
google赌的是将来,拼的是明天
十年前或者二十年前你同样可以说java在pc上很慢
今天那就是另外一个故事了

【在 t*****n 的大作中提到】
: android的慢是出了名的。类似的硬件,ios流畅的很。android 3/4搞了个硬件加速,
: 就到处吹嘘。要是足够的快的,还搞什么加速?
: android就是移动os史一个笑话。每天用同样的硬件,要什么虚拟机?

avatar
g*g
40
市场不是以小码农个人意志为转移的。要吗随波逐流,要吗被扒掉底裤。

【在 z****e 的大作中提到】
: 这就是你跟google的差距
: google赌的是将来,拼的是明天
: 十年前或者二十年前你同样可以说java在pc上很慢
: 今天那就是另外一个故事了

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。