secondwtq's repos on GitHub
HTML · 5 人关注
Ares_Ex1
A small extended version of Ares Yuri's Revenge Extension.
OCaml · 2 人关注
cfp
CSS · 2 人关注
hacking_into_iTunes
[Web] Music metadata search page with iTunes API.
1 人关注
7Tsh
A Test Shell.
1 人关注
awesome-compiler
A curated? list of awesome compiler-related projects, tutorials and courses.
TypeScript · 1 人关注
binpacker
React sprite packer (for games, etc.)
Jupyter Notebook · 1 人关注
blender-benchmark-analysis
OCaml · 1 人关注
bmon
Watch and download specified live stream channel of bilibili. (Strictly Linux ONLY!)
C++ · 1 人关注
chandragupta
TypeScript · 1 人关注
DefinitelyTyped
The repository for high quality TypeScript type definitions.
Emacs Lisp · 1 人关注
doom-emacs
An Emacs configuration for the stubborn martian vimmer
Shell · 1 人关注
dotfiles
JavaScript · 1 人关注
ease
slEep As a SErvice.
C++ · 1 人关注
einstein
HTML · 1 人关注
expressus
JavaScript · 1 人关注
exturl
TypeScript · 1 人关注
fullslide
TypeScript · 1 人关注
gather
C++ · 1 人关注
HOWARD11
1 人关注
HOWARDAssets
C++ · 1 人关注
IllybLauncher
C++ · 1 人关注
IllybLauncherRocket
1 人关注
Interfacer
C++ · 1 人关注
Kaleidoscope
Lua · 1 人关注
luajit-lang-toolkit
A Lua bytecode compiler written in Lua itself for didactic purposes or for new language implementations
Haskell · 1 人关注
marskow
C++ · 1 人关注
MarXsCube
Project MarXsCube. A 2(.5)D game engine (mainly for RTS) with (a small) C++ Core and (modified) Lua for extension.
JavaScript · 1 人关注
Meow
A Web Simple Collaboration Markdown Editor
Go · 1 人关注
miniflux
Minimalist feed reader written in Go and Postgresql, with my customizations.
1 人关注
mirage
secondwtq

secondwtq

V2EX 第 81805 号会员,加入于 2014-11-16 03:41:33 +08:00
《命令与征服》重置版将以 GPL 3.0 协议开放部分源代码
  •  1   
    Steam  •  secondwtq  •  2021-12-01 13:12:00 PM  •  最后回复来自 levelworm
    7
    又到了让诸位 V 友做人生导师的时候了,关于要不要读研。
    职场话题  •  secondwtq  •  2017-04-22 13:39:18 PM  •  最后回复来自 cpygui
    79
    请教几个关于订票网站的设计问题
    问与答  •  secondwtq  •  2016-01-05 15:22:59 PM
    日经一下, Google 首页改版了?
    分享发现  •  secondwtq  •  2015-09-03 00:18:11 AM  •  最后回复来自 acess
    29
    求推荐一款适合折腾的无线路由器
    问与答  •  secondwtq  •  2015-05-16 09:32:34 AM  •  最后回复来自 Dreista
    14
    secondwtq 最近回复了
    1 天前
    回复了 z0z 创建的主题 新手求助 现在学 Swift 开发前途光明吗?
    美国有可能会禁掉中国的 swift ,自己看着办吧
    10 天前
    回复了 waiaan 创建的主题 JavaScript 这段 if...else 有优雅的写法吗?
    我怎么感觉如果这是 C/C++ 的代码的话,主楼原本的写法就挺好的 ...
    Code Interpreter 不知道,但是 Function Calling 的能力的话,一般认为 OpenAI 是对其模型进行了专门训练才能达到如此的效果。开源模型如果没经过类似的训练的话只能在 Prompt 上做手脚,结合限制输出 token 的手段。目前 Llama 系列官方模型都没有 FunctionCalling 的训练。
    github.com/MeetKai/functionary MeetKai/functionary: Chat language model that can use tools and interpret the results 这里倒是有个原生支持 Function Calling 的
    11 天前
    回复了 EricYuan1 创建的主题 macOS 有没有大佬关于 macos 软件开发的教程
    www.youtube.com/@AppleProgramming AppleProgramming - YouTube
    油管上的老哥,教程从 C 出到 ObjC 再过渡到 Swift
    8B 的跟 GPT-4 比不太现实吧,至少得 70B 那个,后面还有 400B 的
    22 天前
    回复了 Rorysky 创建的主题 Linux 当前最性感的发行版是否是 NixOS
    @moonjourney 我不是说个别包里的个别 hack ,而是 nix 的整个 approach 像个 hack
    ARK 上 QSV 是有的 www.intel.com/content/www/us/en/products/sku/80917/intel-xeon-processor-e31226-v3-8m-cache-3-30-ghz/specifications.html Intel® Xeon® Processor E3-1226 v3
    可以多试几个软件看看
    23 天前
    回复了 Rorysky 创建的主题 Linux 当前最性感的发行版是否是 NixOS
    不同 distro 方向不同不能比较
    比如对我更有吸引力的可能是 CachyOS 和 Clear Linux 这种

    Nix 的问题我觉得是 UNIX 生态下很多程序是依赖于这套文件系统的,强行变成另一种模式让人觉得这玩意是一个巨大的 hack ,反而不 cool 了,所以我试了两天就不再用了。
    @FightPig
    说的是这个 world.hey.com/dhh/fonts-don-t-have-to-look-awful-on-windows-564c9d2f Fonts don't have to look awful on Windows 还有这个 twitter.com/dhh/status/1762595923857903860 DHH on X: "That crazy 8K Dell monitor came in, and the text is so fucking crisp, it's hard to convey in words. Substantial step up over the 6K Pro Display. But... there's a caveat. It basically doesn't work in dark mode. The thing is a mirror. Is this good enough to give up on dark mode? " / X ?

    他的意思应该是 Retina 级别就可以了,他是先用的 Pro Display XDR ,然后觉得很不错,换了 8k 之后更好了由奢入俭难了。这个和楼主的看法是相反的,DHH 认为硬件到了一个 baseline 之后下两边是没啥差距的。对于桌面系统这个 baseline 就是苹果惯用的 218 dpi 左右(即 27 寸 5K ,32 寸 6K ),不难发现现在 PC 主流的 HiDPI 硬件比这个低了至少一个等级,但是还没到 8k 那么夸张。

    不过这个说法也就仅供参考,毕竟他还说:
    > I just spent last week using a PC on a 27" 4K monitor (163 PPI) where I accidentally committed the other common cardinal sin that make fonts look like shit on any system: Fractional scaling. I had the screen set to 150%. No wonder it looked offensively bad compared to the Mac! You can't split a pixel, so the system has to do all sorts of typographically nasty tricks when doing non-integer scaling, and the end result is awful font rendering.

    我是看不出 fractional scaling 和字体渲染之间有啥必然联系,正确实现的 fractional scaling 不需要在字体渲染级别 split a pixel 。结合他给出的引用,他很有可能搞混了 fractional scaling 和 subpixel rendering 。
    每个 ISA 都有自己的坑,不好说哪个编译起来更复杂。同一个编译器,不同后端下的功夫也不一样,你可以只做最基本的指令选择寄存器分配,不做优化,就说我编译没编译吧。就不说不同编译器版本和编译选项的坑了。这个还可以套娃:就是你编译器本身是怎么编译的?就不说拿 -O0 的编译器来跑这种老六行为,就现有主流编译器,过一遍 LTO+PGO 或者 post-link optimization 就能有两位数百分点的提升。

    最好还是统一编译到同一架构来比较。
    而这个图压根没有给出任何相关信息,作为性能比较是不合格的。


    @agagega #6
    > 编译时间绝对大头肯定是优化,这部分和目标平台没啥关系。
    感觉真不一定,几个重量级:C++,Rust ,Haskell ,Scala
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   6073 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 02:14 · PVG 10:14 · LAX 19:14 · JFK 22:14
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.