xuejie (u/xuejie) - Readit News

xuejie commented on Intel's woes with Core i9 CPUs crashing look worse than we thought techradar.com/computing/c... · Posted by u/signa11

jclay · a year ago

I'll also add that I was never able to get the instability to show up when running the classic stress testing tools: MemBench, Prime95, and Intel's own stability tests could all run for hours and pass.

There's something unique about the workload of ninja launching a bunch of clang processes that draws this out.

On my machine, a clean build of the llvm-project would consistently fail to complete, so that may be a reasonable workload to A/B test with if you're looking into this.

The user quoted above was running gentoo builds on specific p-cores to test various solutions, ultimately finding that the p-core limit was the only fix that yielded stability.

xuejie · a year ago

Just provide a not-related-at-all but IMHO still interesting case: I used to have a Kioxia CM6 U2 SSD drive, it would pass all sorts of benchmarks the reseller is willing to run, but whenever I tried to clean-compile Rust on it, the drive would fail almost certainly somewhere in the build process. While there are configurations you can compile Rust using pre-built LLVM, in my tests I'm compiling LLVM along the way. So I can agree with the comment here, there might be some unique property when doing multi-core compilations, though my tests show a potentially faulty drive, while the above comment here is about Intel CPU.

xuejie commented on micro – A Modern Alternative to nano micro-editor.github.io/... · Posted by u/theycallhermax

zyedidia · 2 years ago

A big reason is because I started a working towards a PhD recently, and so I've been more focused on that. I think micro has also reached a relatively stable spot, where it would only be significantly improved with some large new features. It is serving its purpose well as a simple/familiar terminal-based editor. I have plans to give it more love and release a version 3, but no timeframe.

xuejie · 2 years ago

Like other comments here, just want to say thank you for this amazing editor! It has been my primary code editor for the past few years. I did use a few different editors for specific purposes(vscode for interactively proving coq code, joe/nvi for editing super large files), but micro does provide what I need in 90% of the cases :P

xuejie commented on micro – A Modern Alternative to nano micro-editor.github.io/... · Posted by u/theycallhermax

xuejie · 2 years ago

I've been using micro as my main code editor(well I do use vscode for writing coq but that's the only exception) after 10+ years' time with emacs. I simply treat micro as the modern compromised version of acme. It almost has all the features to support the core idea of acme, I have written a plugin to exploit this direction: https://github.com/xxuejie/micro-acme So far it has been working perfectly for me.

xuejie commented on The Text Editor Sam sam.cat-v.org... · Posted by u/bluedino

somat · 2 years ago

The best part of sam are the structural regular expressions. I keep a copy installed just for them. Now admittedly I never use it enough to get good at it so every time it is usually 10 minutes swearing at the manual.

The standard unix regular expression implementations (grep, sed, ed, vi) are very tied to "lines" of text, and most of the time this is exactly what you want. but sometimes it gets in the way. And when you start to have trouble with your regex because it is conflicting with line returns, then it is the sam editor and it's structural regex engines time to shine. They would probably be great elsewhere, but nobody else uses them.

xuejie · 2 years ago

Also a fan of structural regular expressions in the exact same shoes that every time when I try to use it it's an unpleasant experience. Maybe I'm just not good enough at it.

That being said, I've been recently employing comby (https://comby.dev/) in my workflow, which solves similar problem, but understands certain languages to simplify the usage.

xuejie commented on Turing Pi 2: 4 Raspberry Pi nodes on a mini ITX board jeffgeerling.com/blog/202... · Posted by u/geerlingguy

bullen · 4 years ago

I always reply to these comments because well they are simply wrong for regular Raspberry clusters (this one is stupid though, but still fun to watch):

1) The Raspberry Pi 4 is THE cheapest 2Gflops/W computer ever made and probably that will ever be made in the future too! Peak of energy/resources/lithography/architectures and velocity of money against that, will most likely make it so.

2) You can scale the Raspberry cluster as you want it, only power the nodes you need, it's modular, one breaks you still have a few left, same for the SD cards which BTW while being so slow a Raspberry 2 (2W!) can saturate them they are SURPRISINGLY sturdy (my original SanDisc (every other brand has been a complete scam) are on their 7th year of 99.999% uptime, down when my power company cut the electricity for an hour).

3) The Raspberry cluster is smaller, cooler and silent (if passively cooled, it's the most powerful device that can be fully passively cooled at 100% CPU (7W) without becoming too hot to wear early) and wont fail because of failing fans!

4) For battery backup there is nothing better because beyond total of 100W for 24 hours you start to see the limits of what is practical to manage on a individual basis.

I post this picture every time: http://move.rupy.se/file/final_pi_2_4_hybrid.png (this is how you cool a Raspberry 2/4 hybrid cluster)

xuejie · 4 years ago

> The Raspberry Pi 4 is THE cheapest 2Gflops/W computer ever made and probably that will ever be made in the future too!

Can you expand on this one? I was curious why you think there probably will not be a cheaper one in the future with similar or better specs.

xuejie commented on A distributed key value store in under 1000 lines github.com/geohot/minikey... · Posted by u/Triv888

xuejie · 5 years ago

Reminds me of the first version of Redis in tcl: https://gist.github.com/antirez/6ca04dd191bdb82aad9fb241013e...

xuejie commented on Fastly hires entire Wasmtime team from Mozilla bytecodealliance.org/arti... · Posted by u/swyx

nullifidian · 5 years ago

RISC-V is from a significantly differing category. A category for WASM doesn't really exist yet, there is nothing else like this -- a relatively low level bytecode language with high-level features such as nominal types, garbage collection, modules.

xuejie · 5 years ago

IMO such a category existed for quite a long time, JVM and .NET all falls into this category. Yes WASM has its fame for becoming a browser standard, but fundamentally, there is very little difference between WASM and JVM.

xuejie commented on I am seriously considering going back to desktop computers misc-stuff.terraaeon.com/... · Posted by u/sT370ma2

xuejie · 5 years ago

Personally, I already pulled the trigger 2 years ago when I first starting to write Rust professionally. A laptop just becomes far tooooo noisy compiling Rust code. These days I use 3 machines:

* A fanless Chromebook with decent screen for travel use

* An Intel NUC that is hooked to a big monitor, which is also the device I'm typing this on

* A beefy Ryzen desktop that sits in the corner of my balcony, which I usually connect via ssh and perform all the heavy tasks

To me I'm getting all the benefits of each computer, and the combined cost is still less than a so-called macbook pro :)

xuejie commented on Why Not Rust? matklad.github.io/2020/09... · Posted by u/dochtman

the_duke · 5 years ago

> Haskell

I adore Haskell, but my personal problems with it:

* Records! Lenses are fine, but a huge complexity increase. I love the recently accepted record syntax RFC though, this will make things a lot nicer.

* I feel like the plethora of (partially incompatible) extensions make the language very complicated and messy. There is no single Haskell. Each file can be GHC Haskell with OverloadedStrings or GADTs or ....

* Library ecosystem: often I didn't find libraries I needed. Or they were abandoned, or had no documentation whatsoever, or used some fancy dependency I didn't understand. Or all of the above...

* Complexity. I can deal with monads, but some parts of the ecosystem get much more type-theory heavy than that. Rust is close enough to common programming idioms that most of it can be understood fairly quickly

* Build system ( Cabal, Stackage, Nix packages, ... ? ), tooling (IDE support etc)

> F#

I admittedly haven't tried F# since .net core. I just remember it being very Windows-centric and closely tied to parts of the C# ecosystem, which brings similar concerns as in my sibling comments about Java.

> if you need a c library, you can build a 'trusted' wrapper around it as easily in rust as with any other language.

Sure, but if that wrapper does not exist, you have to build it yourself. I can say from experience that writing an idiomatic, safe Rust wrapper for a C library is far from trivial, so you lose the "I don't have to worry about memory unsafety" property.

xuejie · 5 years ago

> I feel like the plethora of (partially incompatible) extensions make the language very complicated and messy. There is no single Haskell. Each file can be GHC Haskell with OverloadedStrings or GADTs or ....

Aren't macros, especially proc macros these days in Rust having the same effect? Personally I feel like this is a tradeoff every language has to play with: you either limit to a special way of writing, or adding some sort of ad-hoc system that enables rewriting syntax and even to a degree, semantics.

xuejie commented on Why is Idris 2 so much faster than Idris 1? type-driven.org.uk/edwinb... · Posted by u/culturedsystems

xuejie · 5 years ago

The author first goes with:

> Idris 1 is implemented in Haskell, but that has little (if anything) to do with the difference.

But latter they also go on to say:

> Idris 2 benefits from a robust, well-engineered and optimised run time system, by compiling to Chez Scheme.

I must say I'm slightly confused here. Yes a rewrite might also enable to avoid all the legacy part that might slow down the code, but what is also possible, is that a new language and a new runtime could enable new optimizations that are not possible before. The author did mention Chez's profiling tools help a lot in the rewrite. So I was curious: is it really true, that we cannot attribute some part of the speedup to language differences?

Also I was interested in the rationale behind using Scheme to replace Haskell, but I failed to find some reasoning behind this, anyone can shed some light on this?

xuejie · 5 years ago

Thanks guys for the explanation! I truly have misunderstood this post.