V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  ipwx  ›  全部回复第 33 页 / 共 195 页
回复总数  3895
1 ... 29  30  31  32  33  34  35  36  37  38 ... 195  
2021-12-21 17:31:45 +08:00
回复了 makeitworks 创建的主题 MacBook Pro 新的 mac 跑 intellij 编译 scala 工程速度不给力啊
看上去 JDK 相当不给力啊。不过也对,毕竟 JVM 有很多 JIT 技术,大概在 ARM 上还不行。

反正我用 pytorch 跑神经网络,m1 pro 对比 2018 年 i5 的 macbook pro ,可以快 2 倍。
2021-12-21 17:17:27 +08:00
回复了 LaGeNanRen 创建的主题 生活 觉得每天自己的时间好短,为啥又穷又忙没钱还没时间
"9.00 ~ 10.30csgo" 去掉就行
2021-12-21 10:30:33 +08:00
回复了 fusluv 创建的主题 职场话题 要不要应届去体制内
@leeolsen 像我的性格,别说体制内了,我都受不了互联网大厂的约束。除了创业成功我想不出我能如愿的第二条路。
2021-12-21 10:29:39 +08:00
回复了 fusluv 创建的主题 职场话题 要不要应届去体制内
@leeolsen 你这算是活通透了。可是大部分人根本来不及活通透就得选择了。
好办法就是上传源码(滑稽
2021-12-17 15:37:02 +08:00
回复了 kingofzihua 创建的主题 Linux 问一个协程方面的问题
@lxdlam 你说的很对,所以虽然我个人不喜欢 2333 ,虽然 Go 是一种工程妥协( Go 到处是工程妥协,比如现在还没完全上线的泛型),但是它毫无疑问是有用的。可以说 Go 语言这种编译器抽象对于大部分 Web 应用都是有效的,这本就是它的专长。

无效的领域,其实倒也不少。比如追求精确控制延迟的 real-time system 、高频交易之类的低延迟系统;比如本来就需要精确控制所有开销的游戏引擎、OS 内核、数据库系统。比如各种传统计算机算法。比如科学计算…… 但说实话这些本来就不是 Go 的专长。

我对于本楼有些微词的地方是,明明有这么多不同的场景,很多 Go 语言拥蹙就只知道互联网业务这一亩三分地,以为 Go 的协程就是圣经。。。互联网程序员现在网上的声音太大了,以至于 “技术” 就只有互联网并发 hhh
2021-12-17 14:43:00 +08:00
回复了 kingofzihua 创建的主题 Linux 问一个协程方面的问题
@statumer C# 那种可以通过一个线程池(专门排队做阻塞任务) + 非阻塞的 IO 。不过确实,非阻塞 IO 的库开发需要时间。所以这就造成了 Go 语言在网络微服务等领域特别被人追捧,因为在这里面编译期自动插入 hook 确实省事得多,一下子就可以适配所有阻塞的库。

这其实就是工程性的妥协了。C++ 和 C# 没有编译器的 hack ,导致大家不得不开发真正的非阻塞库。但是反过来,这样就倒逼 C++ C# 这种语言用户开发出真正高性能的非阻塞库了。然而毕竟真正需要高性能非阻塞的库不多,Network IO, MySQL / PostgreSQL / MongoDB ,加上一定的 File IO 和基础框架,就解决了。

其他的并不需要处理这种事情。应用逻辑方面需要解决“锁”的阻塞问题,其实“不阻塞”才是更正确的方案。逻辑复杂的应用从多线程并发阻塞模型换成 Actor model ,你会发现写起来就是第二次工业革命和第三次工业革命的区别。

Go 语言编译器允许大家偷懒,大家自然没有动力去精益求精,“够用就行”。反而抑制了更精巧的程序 —— 当然这也是做 “工作” 和做 “艺术品” 态度的差别吧 hhh
2021-12-17 14:34:19 +08:00
回复了 kingofzihua 创建的主题 Linux 问一个协程方面的问题
@lxdlam 在我看来 f(n) 就应该也是 async 的,虽然对于这方面 js 我不太熟。

我的技术背景是 C++、Python 比较熟,曾经用 Scala 写过 Future / Promise 的程序不过已经很久没有用了。C++ 自己写过 Actor framework ,Python 曾经用过 tornado 和 gevent ,现在挺喜欢用 async / await 。

因为我的这些背景,所以我觉得程序员非常准确明白所有这些并发方法(线程池、event loop 、callback 、future promise 、async await )是基本功,而且不同任务可能偏重于不同的技术。当一个任务需要特别准确把握延迟的时候,随意上下文切换是不可接受的,那么就得手撸 event loop ,顶多在 event loop 上自己封装一下比如 actor model 或者 future / promise 呗。

所以我比较 anti go 语言这种类似于线程的协程吧,总感觉它管得太多了。
2021-12-17 01:33:36 +08:00
回复了 kingofzihua 创建的主题 Linux 问一个协程方面的问题
@statumer 我原先也完全是你这个理解思路,直到我在这一楼层里面看到了有人说 Go 语言的协程是可以切换上下文的——

https://www.jianshu.com/p/fb1ccbd0d0ff

我 tm ,瞬间五雷轰顶,并且明白了为啥 Go 吹那么多的原因。引用我 125L 的观点:

> Go 这种内置协程时间片切分的机制,在我看来,是一种工程实践上的妥协。
> 无论多轻量级的切换,一定是耗时的。减少不必要的切换可以使得总体耗时降到最低。
> 如果能控制 IO 非阻塞让渡控制权,而且每对 IO 之间的操作都比较轻量(微妙级),就完全可以只在 IO 上切换。这样总体效能是最高的。
> 但是工程上不能保证所有类库都这样,也不能保证所有程序员都写的对,所以 Go 的这种协程才有用吧 hhh

所以本质上这是一个,因为不会用 event loop 的程序员太多了,Go 语言大爷们就说:算了,你们这群傻逼,干脆我语言创造一个比系统线程更轻的协程给你们用算了。

----

所以总结一下,Go 语言的协程和其他语言的协程是不同的。C++、Python 这种经典语言的协程 tm 根本不可能内置 Go 虚拟机的时间线分片。JVM 和 C# 也从未想过要这么干。微软的 Fiber 还差羽而归。因为它们发现,替程序员越俎代庖搞这种抽象,吃力不讨好。反正追求性能的有 event loop 或者基于 event loop 的单线程协程,为啥还要搞个不上不下的多线程(有上下文切换)的协程呢?

毕竟任何上下文切换,哪怕你说 Go 协程切换只要三个寄存器,tm 还是实打实有这个耗时的啊。
----

但是在一个没有泛型被认为是大道至简的语言里面,这种独一份的奇葩设计也没啥可奇怪的。
2021-12-16 16:47:59 +08:00
回复了 zzzain46 创建的主题 问与答 同样一个 csv,为什么导入 db2 比导入 MySQL 快很多
(强烈怀疑它没有优化好
(要用 transaction batch insert
2021-12-16 16:43:41 +08:00
回复了 zzzain46 创建的主题 问与答 同样一个 csv,为什么导入 db2 比导入 MySQL 快很多
你用了啥工具导入。。。有区别的
2021-12-16 15:10:58 +08:00
回复了 dwlovelife 创建的主题 程序员 最近学 Python ,关于作用域的问题有点不明白
如果你在 foo 里面 a = 200 ,然后在 foo() 之后 print(a),你会发现 foo 里面的 a 和外面的 a 就不是一个 a 了。

我觉得这是 Python 让人不满意的地方。因为没有声明,赋值即声明,所以会搞不清楚作用域。

事实上如果你运行如下代码:

def main():
....print(a)
....a = 1

a = 2
main()

你会得到一个异常:

UnboundLocalError: local variable 'a' referenced before assignment

原因是 a = 1 这句话在 main 函数里面定义了一个变量 a ,因此你在 print(a) 这一行就引用不到全局的 a 了。
2021-12-16 11:10:48 +08:00
回复了 rophie123 创建的主题 Node.js nodejs 前后端一把梭的优势在哪?
@ob 你可以用 bootstrap-vue ( doge )

https://bootstrap-vue.org/
2021-12-16 00:40:13 +08:00
回复了 rophie123 创建的主题 Node.js nodejs 前后端一把梭的优势在哪?
1. vue.js + webpack 配合其他语言不是难事,比如我经常配合 python 。
2. vue.js 就是比 html bootstrap jquery 好写啊。。。
2021-12-15 17:54:04 +08:00
回复了 liuidetmks 创建的主题 程序员 v 站有 C 程序员使用 protothreads 协程吗?
@liuidetmks 哦原来 C 语言的模拟 coroutine 其实是自动机 hhh

这样来看,这种其实更类似于 on_message(message_type) {
switch (message_type) {
case xx: ...
case xx: ...
}
}

只不过用了语法糖自动展开了
2021-12-15 13:44:23 +08:00
回复了 Livid 创建的主题 Python Snakeware
@kidonng Python 的标记收集 GC 很少运行啊,大部分 gc 都分摊在每一行上面了
2021-12-14 13:39:18 +08:00
回复了 kingofzihua 创建的主题 Linux 问一个协程方面的问题
@joshu 说实话,Go 这种内置协程时间片切分的机制,在我看来,是一种工程实践上的妥协。

无论多轻量级的切换,一定是耗时的。减少不必要的切换可以使得总体耗时降到最低。你不会想要一个 for (1000000) 的计算任务被打断一千次吧,对吧对吧。

如果你能控制 IO 非阻塞让渡控制权,而且每对 IO 之间的操作都比较轻量(微妙级),你完全可以只在 IO 上切换。这样总体效能是最高的。

但是工程上不能保证所有类库都这样,也不能保证所有程序员都写的对,所以 Go 的这种协程才有用吧 hhh
1 ... 29  30  31  32  33  34  35  36  37  38 ... 195  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1778 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 45ms · UTC 16:42 · PVG 00:42 · LAX 09:42 · JFK 12:42
Developed with CodeLauncher
♥ Do have faith in what you're doing.