I can't speak to fsspec, but their filesystem functionality (eg. `ls`, `cp`) isn't something that smart_open has and it does look cool.
576 karma · joined August 7, 2016
I can't speak to fsspec, but their filesystem functionality (eg. `ls`, `cp`) isn't something that smart_open has and it does look cool.
Thank you for maintaining StGit — I really enjoy it as a tool! topgit is fine, but quite heavy. I don't use stg much at work with squash merge workflows, but I love it for personal projects or when I need to work on a series of commits with intricate change sequencing.
"Xuantie-910: A Commercial Multi-Core 12-Stage Pipeline Out-of-Order 64-bit High Performance RISC-V Processor with Vector Extension"
From "VIII. NON-STANDARD INSTRUCTION SET EXTENSION"
Targeting at various industrial applications, XT-910 enables a set of custom non-standard instructions, additional to the standard RISC-V instructions. The non-standard instruction extension can be categorized into two groups based on the purposes - memory access enhancement, and basic arithmetic operation enhancement.
A. Memory access enhancement
Memory access instructions usually account for a high proportion in the total number of instructions, so enhancing memory access instructions can directly benefit the overall performance. By analyzing the mainstream applications running on RISC-V, we observed that for the basic RISC-V instructions there is still quite some room for improvement in memory access related instructions.
First, we support register + register addressing mode, and support indexed load and store instructions. This type of instruction extension reduces the usage of the registers for calculation and reduces the number of instructions for address generation, thereby effectively accelerating the data access of a loop body. Second, unsigned extension during address generation is supported. Otherwise, the basic instruction set does not support direct unsigned extension from 32-bit data to 64-bit data, resulting in too many shift instructions.
I'm not certain if they break out the results by individual optimization, but in Fig. 20 in the paper it looks like all their tweaks add up to a 20% boost over the standard RISC-V ISA. Pretty huge.
Foreign data wrappers are another thing that might be compelling — dunno if Snowflake has an equivalent.
I don't have any numbers but PG has served me fine for basic pseudo-warehousing. Relative to real solutions, it's pretty bad at truly columnar workloads: scans across a small number of columns in wide tables. The "Use Fewer Columns" advice FTA is solid. This hasn't been a deal breaker though. Analytical query time has been fine if not great up to low tens of GB table size, beyond that it gets rough.
[1] https://www.theguardian.com/lifeandstyle/2016/may/18/womens-...
Branch predictors like low entropy (unsurprising) branches, but binary search is algorithmically fast because it maximizes the entropy (information gained) from the few branch checks that it does make.
The 3080 and 3090 are the singular exception. The GDDR6X runs extremely hot and frankly I think it's going to cause a bunch of early failures for even non-mining cards.
On page 5 they tally it up as a $400 difference vs building your own.
Their cloud sync and UPS functionality have been great (flaky power around here). Haven't dug into the TrueNAS' ZFS pool/snapshot management and jails management (FreeBSD's containers) functionality, but both are compelling once I get time and a good project for them. The NAS performing so well has me itching to upgrade to 10 gigabit ethernet around the house once prices come down a bit.
Also I ran the OS off mirrored thumb drives until recently. That was pretty nifty.
I had thought they were illegal, but Wikipedia says otherwise.
At risk of extreme overkill the other way, something like Debezium [1] doing change monitoring dumping into S3 might be a viable industrial strength approach. I haven't used it in production, but have been looking for appropriate time to try it.
Elixir's pipe is the same thing, though Clojure has a few extra forms to facilitate other variable passing patterns.
Speaking as a product leader who has been in a position to decide on these, I'm not opposed to major UI overhauls, but many that have been proposed to me:
- Are motivated by a design team that wants to justify their jobs or make a mark on a product, with the UI considerations secondary.
- Have major issues and design weaknesses themselves.
- Throw out important aspects of functionality in an attempt to be "fresh and simple".
- Ignore that we had our last major overhaul 12 months ago, and that one was in response to the major ovehaul 24 months ago.
Requiring evolution rather than revolution is a hedge against these problems. I'm not generally opposed to overhauls because I'm familiar with the importance of UI. For example, I'm very unhappy with Robinhood as a trading platform, but damn, switching to Fidelity is painful because their UI is so terrible.
I wish I more consistently got to work with talented designers. I put a lot of effort into getting good designers, as poor designers can wreak havoc.
Diffing: 0%| | 153/93195 [30:02<151:31:17, 5.86s/it]
Tightening Fringe Diagonal 82 of 792: 48%|...| 7453/15514 [00:30<00:35, 226.08it/s] Diffing: 0% ... 0/93195 [00:00<?, ?it/s]
Tightening Fringe Diagonal 48 of 792: ...