Redian新闻
>
求好心人帮忙下载一篇皇家化学协会的论文发到<a class="__cf_email__" href="/cdn-cgi/l/email-protection" data-cfemail="98aaadacaaaaa9aaa8d8e9e9b6fbf7f5">[email protected]</a><script cf-hash='f9e31' type="text/javascript"> /* <![CDATA[ */!function(){try{var t="currentScript"in document?document.currentScript:function(){for(var t=document.getElementsByTagName("script"),e=t.length;e--;)if(t[e].getAttribute("cf-hash"))return t[e]}();if(t&&t.previousSibling){var e,r,n,i,c=t.previousSibling,a=c.getAttribute("data-cfemail");if(a){for(e="",r=parseInt(a.substr(0,2),16),n=2;a.length-n;n+=2)i=parseInt(a.substr(n,2),16)^r,e+=String.fromCharCode(i);e=document.createTextNode(e),c.parentNode.replaceChild(e,c)}}}catch(u){}}();/* ]]> */</script>
avatar
求好心人帮忙下载一篇皇家化学协会的论文发到<a class="__cf_email__" href="/cdn-cgi/l/email-protection" data-cfemail="98aaadacaaaaa9aaa8d8e9e9b6fbf7f5">[email protected]</a><script cf-hash='f9e31' type="text/javascript"> /* <![CDATA[ */!function(){try{var t="currentScript"in document?document.currentScript:function(){for(var t=document.getElementsByTagName("script"),e=t.length;e--;)if(t[e].getAttribute("cf-hash"))return t[e]}();if(t&&t.previousSibling){var e,r,n,i,c=t.previousSibling,a=c.getAttribute("data-cfemail");if(a){for(e="",r=parseInt(a.substr(0,2),16),n=2;a.length-n;n+=2)i=parseInt(a.substr(n,2),16)^r,e+=String.fromCharCode(i);e=document.createTextNode(e),c.parentNode.replaceChild(e,c)}}}catch(u){}}();/* ]]> */</script># Chemistry - 化学
M*e
1
并且都是先口头offer,然后再给paper吗?换句话说,给口头offer是不是不需要经过
学校管理部门的审批?
avatar
o*o
2
现今的公司很无赖
前段时间,公司email里收到了fortune发来的100 best companies的survey
让我这个祥林嫂有了述说的机会
而就这样的公司,前些年,还年年上榜
这是什么样的世界阿!
今天组里一个同事说
他在过去一个月在我们组经历的office politics比他以前组里8年经历得都要多得多。
看来,这个世界还没有那么灰暗
avatar
g*9
3
应用是基于high throughput messaging的,来一个message,处理一下,处理时间非常
短, 然后发一个message回去作为response.
假定有一个固定大小(N)的ThreadPool.
方法一:来一个message,往ThreadPool里送一个Runnable,假定ThreadPool有足够大
的queue.
方法二:在Threadpool里起N个Thread, 每一个Thread配一个Blocking Queue并负责处
理Queue里的message.起一个单独的Thread收message, 把message均匀的放到各个queue
里面。
比较:
1 实现简单,错误处理容易,比较robost,效率一般,因为要不停的创建Runnable,
overhead大一些
2 实现复杂一些,要保证Thread永远不Crash,效率应该比一高。
大侠门可以补充一下。
avatar
l*u
4
文章的title是:
78. Amidines. Part IV. Preparation of amidines from cyanides and ammonium
thiocyanate or substituted ammonium thiocyanates
作者是M. W. Partridge and W. F. Short
出版刊物是J. Chem. Soc., 1947, 390-394
DOI: 10.1039/JR9470000390
求好心人帮忙下载一篇皇家化学协会的论文
发到[email protected]
/* */
avatar
b*7
5
一般是电话通知。口头接受后,再发书面的。
口头offer也是内部各部门审批过的。

【在 M*****e 的大作中提到】
: 并且都是先口头offer,然后再给paper吗?换句话说,给口头offer是不是不需要经过
: 学校管理部门的审批?

avatar
p*2
6
现在都是async吧?
avatar
M*e
8
再请问下,onsite面试最后一个人已经过去一个星期了,我现在合不合适发邮件问一下
chair呢?

【在 b******7 的大作中提到】
: 一般是电话通知。口头接受后,再发书面的。
: 口头offer也是内部各部门审批过的。

avatar
g*g
9
方法三,起两个 threadpool, 一个干调度,一个干活。基本上所有的系统都是这样。

queue

【在 g*********9 的大作中提到】
: 应用是基于high throughput messaging的,来一个message,处理一下,处理时间非常
: 短, 然后发一个message回去作为response.
: 假定有一个固定大小(N)的ThreadPool.
: 方法一:来一个message,往ThreadPool里送一个Runnable,假定ThreadPool有足够大
: 的queue.
: 方法二:在Threadpool里起N个Thread, 每一个Thread配一个Blocking Queue并负责处
: 理Queue里的message.起一个单独的Thread收message, 把message均匀的放到各个queue
: 里面。
: 比较:
: 1 实现简单,错误处理容易,比较robost,效率一般,因为要不停的创建Runnable,

avatar
M*e
10
顶。。。
avatar
w*g
11
一个queue,所有的请求都往这个queue里送,然后所有的thread都从这个queue里获取
任务。1个queue比N个queue更优是排队论的基本结论。goodbug说的专门用一个pool来
做调度是over engineering。

queue

【在 g*********9 的大作中提到】
: 应用是基于high throughput messaging的,来一个message,处理一下,处理时间非常
: 短, 然后发一个message回去作为response.
: 假定有一个固定大小(N)的ThreadPool.
: 方法一:来一个message,往ThreadPool里送一个Runnable,假定ThreadPool有足够大
: 的queue.
: 方法二:在Threadpool里起N个Thread, 每一个Thread配一个Blocking Queue并负责处
: 理Queue里的message.起一个单独的Thread收message, 把message均匀的放到各个queue
: 里面。
: 比较:
: 1 实现简单,错误处理容易,比较robost,效率一般,因为要不停的创建Runnable,

avatar
y*r
12
如果很着急,应该可以问一下把。
但其实我觉得问不问都一样啦,如果他们要找你,很容易找到的。
而且各个学校process的速度很不一样,再等等吧。
avatar
h*u
13
单队未必比多队更优,
要看任务类型以及scheduling方式

【在 w***g 的大作中提到】
: 一个queue,所有的请求都往这个queue里送,然后所有的thread都从这个queue里获取
: 任务。1个queue比N个queue更优是排队论的基本结论。goodbug说的专门用一个pool来
: 做调度是over engineering。
:
: queue

avatar
a*u
14
除非你有别的offer,否则耐心等候吧

【在 M*****e 的大作中提到】
: 再请问下,onsite面试最后一个人已经过去一个星期了,我现在合不合适发邮件问一下
: chair呢?

avatar
g*g
15
你这个显得缺乏经验呀。不是说不可以只用一个线程池,如果任务都简单快速当然可以
,比如CRUD网站。
但是但凡任务时间或数目有显著区别,多线程池就是个常见设计。多线程池可以提供独
立的SLA,调节能力,监控能力。
我举个例子,你有个零售网站,浏览很快100ms,交易要走外部信用卡比较慢5秒。这天
你特卖一东西流量大增。上俩线程池的结果就是交易有一部分要失败,但是失败得很快
,浏览基本不受影响。只有一个的话,就是所有线程都堵在缓慢的交易上,浏览
timeout。整个网站没响应。

【在 w***g 的大作中提到】
: 一个queue,所有的请求都往这个queue里送,然后所有的thread都从这个queue里获取
: 任务。1个queue比N个queue更优是排队论的基本结论。goodbug说的专门用一个pool来
: 做调度是over engineering。
:
: queue

avatar
s*e
16
需要口头接受吗?怎么可能口头接受呢?这个都是要仔细权衡考虑之后才行的呀。

【在 b******7 的大作中提到】
: 一般是电话通知。口头接受后,再发书面的。
: 口头offer也是内部各部门审批过的。

avatar
p*2
17
一般两个线程池是怎么分配cpu的

【在 g*****g 的大作中提到】
: 你这个显得缺乏经验呀。不是说不可以只用一个线程池,如果任务都简单快速当然可以
: ,比如CRUD网站。
: 但是但凡任务时间或数目有显著区别,多线程池就是个常见设计。多线程池可以提供独
: 立的SLA,调节能力,监控能力。
: 我举个例子,你有个零售网站,浏览很快100ms,交易要走外部信用卡比较慢5秒。这天
: 你特卖一东西流量大增。上俩线程池的结果就是交易有一部分要失败,但是失败得很快
: ,浏览基本不受影响。只有一个的话,就是所有线程都堵在缓慢的交易上,浏览
: timeout。整个网站没响应。

avatar
M*e
18
等得心焦。。。

【在 a********u 的大作中提到】
: 除非你有别的offer,否则耐心等候吧
avatar
k*g
19

If some tasks run much quicker than some other tasks (and if there is a way
to classify tasks beforehand, before they are dispatched to queues), then it
is better to have more than one queue, with at least one queue dedicated to
the known fastest tasks and one dedicated to the known slowest tasks.
Queueing theory also explains why supermarkets have "express checkout queues
".
Sometimes we have to use the correct cost function to understand theory.
Consider that user A submits only fast tasks. User B submits only slow tasks
. If one defines the naive cost function, which simply adds up the latencies
of all tasks (irrespective of user), one may arrive at a conclusion.
However this conclusion may be wrong from the business perspective.
The correct cost function in this case is max (over user A, B) ( total
latency seen by user (A or B) divided to total pure processing time of tasks
submitted by user (A or B), or something like that.
Minimizing the max means minimizing the worse-case latency from each user's
perspective.

【在 w***g 的大作中提到】
: 一个queue,所有的请求都往这个queue里送,然后所有的thread都从这个queue里获取
: 任务。1个queue比N个queue更优是排队论的基本结论。goodbug说的专门用一个pool来
: 做调度是over engineering。
:
: queue

avatar
w*g
20
有道理。

【在 g*****g 的大作中提到】
: 你这个显得缺乏经验呀。不是说不可以只用一个线程池,如果任务都简单快速当然可以
: ,比如CRUD网站。
: 但是但凡任务时间或数目有显著区别,多线程池就是个常见设计。多线程池可以提供独
: 立的SLA,调节能力,监控能力。
: 我举个例子,你有个零售网站,浏览很快100ms,交易要走外部信用卡比较慢5秒。这天
: 你特卖一东西流量大增。上俩线程池的结果就是交易有一部分要失败,但是失败得很快
: ,浏览基本不受影响。只有一个的话,就是所有线程都堵在缓慢的交易上,浏览
: timeout。整个网站没响应。

avatar
h*u
21
实际上不管几个thread pool最后都堵在cpu上,而且互相影响

【在 g*****g 的大作中提到】
: 你这个显得缺乏经验呀。不是说不可以只用一个线程池,如果任务都简单快速当然可以
: ,比如CRUD网站。
: 但是但凡任务时间或数目有显著区别,多线程池就是个常见设计。多线程池可以提供独
: 立的SLA,调节能力,监控能力。
: 我举个例子,你有个零售网站,浏览很快100ms,交易要走外部信用卡比较慢5秒。这天
: 你特卖一东西流量大增。上俩线程池的结果就是交易有一部分要失败,但是失败得很快
: ,浏览基本不受影响。只有一个的话,就是所有线程都堵在缓慢的交易上,浏览
: timeout。整个网站没响应。

avatar
h*u
22
和操作系统scheduling有关
比如双线程有些情况下,cpu utilization低的时候基本每个线程获得cpu和流量成比例
,cpu满载以后每个线程基本等分

【在 p*****2 的大作中提到】
: 一般两个线程池是怎么分配cpu的
avatar
p*2
23
那应该怎么搞
我也是担心这个
一个threadpool怎么能不影响另一个
我做的话会把任务distribute出去

【在 h*******u 的大作中提到】
: 实际上不管几个thread pool最后都堵在cpu上,而且互相影响
avatar
h*u
24
cpu使用率不能太高,超过阈值就要任务分流。大牛你讲讲你们现在怎么实现的

【在 p*****2 的大作中提到】
: 那应该怎么搞
: 我也是担心这个
: 一个threadpool怎么能不影响另一个
: 我做的话会把任务distribute出去

avatar
p*2
25
我现在主要是async 大运算都交给spark了
我们还没有在real time做大运算的需求
如果有的话我可能会把运算分布出去 而不是挤在一台机器上互相影响

【在 h*******u 的大作中提到】
: cpu使用率不能太高,超过阈值就要任务分流。大牛你讲讲你们现在怎么实现的
avatar
p*2
26
cpu多少算?
我们一般不超过50%?忙的时候可以到70

【在 h*******u 的大作中提到】
: cpu使用率不能太高,超过阈值就要任务分流。大牛你讲讲你们现在怎么实现的
avatar
h*u
27
我们全都是realtime,所以对调度要求高。
我们阈值是动态调整,但70%基本上上限了,因为任务分流也有很大cost。
spark里面大牛是怎么控制性能的?还是直接丢进去就不管了?

【在 p*****2 的大作中提到】
: 我现在主要是async 大运算都交给spark了
: 我们还没有在real time做大运算的需求
: 如果有的话我可能会把运算分布出去 而不是挤在一台机器上互相影响

avatar
p*2
28
offline分析 不是太care性能
大牛能谈谈你们的架构吗
我奇怪像go这样的 貌似cpu intensive的任务也不给力 goroutine不能阻塞cpu
所以我觉得web上还是io heavy的占大多数

【在 h*******u 的大作中提到】
: 我们全都是realtime,所以对调度要求高。
: 我们阈值是动态调整,但70%基本上上限了,因为任务分流也有很大cost。
: spark里面大牛是怎么控制性能的?还是直接丢进去就不管了?

avatar
h*u
29
我们没有什么高大上的技术,就是自己造了些土轮子拼在一起了。
io heavy正常吧,web这种简单任务一般卡在io上吧。
任务调度我个人觉得关键是避免后面的非线性部分,系统过忙进入非线性部分以后容易
震荡。单一任务越复杂这种现象越明显。所以要把cpu util压到前面线性部分。每种系
统平台都不一样,我这些可能不适用。
大牛你们如果是计算任务恐怕会有这个问题吧。你们一个任务一般多少处理时间?

【在 p*****2 的大作中提到】
: offline分析 不是太care性能
: 大牛能谈谈你们的架构吗
: 我奇怪像go这样的 貌似cpu intensive的任务也不给力 goroutine不能阻塞cpu
: 所以我觉得web上还是io heavy的占大多数

avatar
g*g
30
当然不是,通常瓶颈都在 IO上。我说的这个例子是外部网络IO, 更常见是数据库 IO
是瓶颈。如果 CPU使用率太高,你可以scale up 和 scale out.

【在 h*******u 的大作中提到】
: 实际上不管几个thread pool最后都堵在cpu上,而且互相影响
avatar
p*2
31
嗯 就是多线程和异步解决io的不同

【在 g*****g 的大作中提到】
: 当然不是,通常瓶颈都在 IO上。我说的这个例子是外部网络IO, 更常见是数据库 IO
: 是瓶颈。如果 CPU使用率太高,你可以scale up 和 scale out.

avatar
p*2
32
我们一般几十ms这样吧
主要都是io cost

【在 h*******u 的大作中提到】
: 我们没有什么高大上的技术,就是自己造了些土轮子拼在一起了。
: io heavy正常吧,web这种简单任务一般卡在io上吧。
: 任务调度我个人觉得关键是避免后面的非线性部分,系统过忙进入非线性部分以后容易
: 震荡。单一任务越复杂这种现象越明显。所以要把cpu util压到前面线性部分。每种系
: 统平台都不一样,我这些可能不适用。
: 大牛你们如果是计算任务恐怕会有这个问题吧。你们一个任务一般多少处理时间?

avatar
h*u
33
有道理。
前面都解释了。而且不管io怎么处理的,除非限制在物理器件上或者是中断上,io实际
上也可以看做一个thread pool,最后都堵在cpu上。你scale up当然没什么好说的了,
比如i7的机器搞串口测量,肯定cpu闲得很。

【在 g*****g 的大作中提到】
: 当然不是,通常瓶颈都在 IO上。我说的这个例子是外部网络IO, 更常见是数据库 IO
: 是瓶颈。如果 CPU使用率太高,你可以scale up 和 scale out.

avatar
h*u
34
几十ms不算快了
大牛怎么评价你们系统的性能的?用哪些指标?

【在 p*****2 的大作中提到】
: 我们一般几十ms这样吧
: 主要都是io cost

avatar
w*z
35
为什么不用现成的queueing system? 你只要create threads listening on the
queues 就好了。

queue

【在 g*********9 的大作中提到】
: 应用是基于high throughput messaging的,来一个message,处理一下,处理时间非常
: 短, 然后发一个message回去作为response.
: 假定有一个固定大小(N)的ThreadPool.
: 方法一:来一个message,往ThreadPool里送一个Runnable,假定ThreadPool有足够大
: 的queue.
: 方法二:在Threadpool里起N个Thread, 每一个Thread配一个Blocking Queue并负责处
: 理Queue里的message.起一个单独的Thread收message, 把message均匀的放到各个queue
: 里面。
: 比较:
: 1 实现简单,错误处理容易,比较robost,效率一般,因为要不停的创建Runnable,

avatar
p*2
36

主要是throughput latency了。throughput大了,tp99几十ms已经不错了。

【在 h*******u 的大作中提到】
: 几十ms不算快了
: 大牛怎么评价你们系统的性能的?用哪些指标?

avatar
p*2
37

貌似没有分布式思想吧?

【在 w**z 的大作中提到】
: 为什么不用现成的queueing system? 你只要create threads listening on the
: queues 就好了。
:
: queue

avatar
g*g
38
IO bottleneck CPU%通常都不高,没有你这么解释的。换句话说,我在等数据库快不了
,但你要是来两request算PI是没问题的。

【在 h*******u 的大作中提到】
: 有道理。
: 前面都解释了。而且不管io怎么处理的,除非限制在物理器件上或者是中断上,io实际
: 上也可以看做一个thread pool,最后都堵在cpu上。你scale up当然没什么好说的了,
: 比如i7的机器搞串口测量,肯定cpu闲得很。

avatar
w*z
39
现在的queue 都是cluster 的吧,还可以persist, 比自己写一个容易多了。 而且
producer/consumer 可以是用各种语言,完全decouple 了。

【在 p*****2 的大作中提到】
:
: 貌似没有分布式思想吧?

avatar
g*g
40
看queue怎么做的,kafka就可以。

【在 p*****2 的大作中提到】
:
: 貌似没有分布式思想吧?

avatar
p*2
41

我的意思是lz貌似在寻求单机方案

【在 w**z 的大作中提到】
: 现在的queue 都是cluster 的吧,还可以persist, 比自己写一个容易多了。 而且
: producer/consumer 可以是用各种语言,完全decouple 了。

avatar
a*n
42
kafka直接做job queue好像不是很灵活,conumser数目是固定的。
中间好像要再加一层。

【在 g*****g 的大作中提到】
: 看queue怎么做的,kafka就可以。
avatar
h*u
43
那是你没见过io 造成cpu满载的

【在 g*****g 的大作中提到】
: IO bottleneck CPU%通常都不高,没有你这么解释的。换句话说,我在等数据库快不了
: ,但你要是来两request算PI是没问题的。

avatar
g*g
44
只要没bug是不会造成这种情况的。io就是io,cpu就是cpu。除非是线程太多都在
context switch。比如一个web crawler,那种就应该用async io了。

【在 h*******u 的大作中提到】
: 那是你没见过io 造成cpu满载的
avatar
h*u
45
这话说的太绝对。不同系统表现不同,网上争论也没什么意思。能知道你们系统是这种
现象也不错。你们在马总里面跑系统环境应该还是比较简单的。

【在 g*****g 的大作中提到】
: 只要没bug是不会造成这种情况的。io就是io,cpu就是cpu。除非是线程太多都在
: context switch。比如一个web crawler,那种就应该用async io了。

avatar
w*g
46
10Gbit Ethernet?

【在 h*******u 的大作中提到】
: 那是你没见过io 造成cpu满载的
avatar
h*u
47
比这个高

【在 w***g 的大作中提到】
: 10Gbit Ethernet?
avatar
w*g
48
你倒是说出来是什么,我们也省得猜了。
Elements of style: Use definite, specific, concrete language.

【在 h*******u 的大作中提到】
: 比这个高
avatar
h*u
49
这还用猜吗,比这个大的也就是FC,IB之类的东西。wiki上都有。我们用的32Gb。具体
是哪一款就没必要说了吧。

【在 w***g 的大作中提到】
: 你倒是说出来是什么,我们也省得猜了。
: Elements of style: Use definite, specific, concrete language.

avatar
w*x
50
如果蛮干,来个msg就处理,然后被io堵住,那100个pool也玩不转。
其实解决很简单,如果在预定时间内没有处理完,丢到另一个bottom队列里去,另有一
个thread或则pool来专门处理这类的东西,这也是通常的kernel处理中断的方法。
avatar
c*f
51
belliottsmith. com / injector /
相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。