Readit News logoReadit News
diamondlovesyou commented on Why are credit card rates so high?   libertystreeteconomics.ne... · Posted by u/voxleone
golergka · a year ago
Looking from the outside, it seems that people in the US are always using credit cards as opposed to debit cards, and I don't really see a good reason for that. I have owned credit card in the past, and I could get one easily now, but I don't see any reason to: I have money in the bank, I want to spend it, and I don't need to lend anything.

Why and how does _credit_ becomes the first and default way of payment?

diamondlovesyou · a year ago
I don't use credit cards for the credit; in fact mine are completely paid for every statement. They are used for the customer protections and other provided "free" benefits. If some scummy or outright scam-y thing is charged to my Amex, I know I will have Amex on my side. If my card is stolen, Amex will refund any fraudulent charges and overnight me a new card; I probably won't get my debit card overnighted, though they will probably refund the fraud. The other thing is credit card points, which are essentially a benefit paid for by credit card processing fees charged to businesses. Many cards also offer access to "private" airport lounges. And other benefits I'm forgetting off the top of my head.

Additionally, having high credit limits, low usage, and older accounts improves credit scores for loans/etc.

No interest is charged if there is no balance carried statement-to-statement, so why bother with silly debit pins and such.

That's how it becomes the default way of payment; it's not really "credit".

diamondlovesyou commented on Xfinity XB3 hardware mod: Disable WiFi and save 2 watts   gist.github.com/pmarks-ne... · Posted by u/p1mrx
sightbroke · a year ago
Why would faster signal attenuation be a good thing?
diamondlovesyou · a year ago
Less area means less sources of interference for others (this property is also true in the other direction). So the attenuation reduces the signal area, and stronger attenuation lets the transmitter be "strong" in the house without the downsides in congested areas.
diamondlovesyou commented on Constant-Time Code: The Pessimist Case [pdf]   eprint.iacr.org/2025/435.... · Posted by u/yuedongze
armchairhacker · a year ago
Why is cooperation unlikely? AFAIK it’s not too hard to make a compiler support a function attribute that says “do not optimize this function at all”; I assume in most compilers the translation and optimization phases are mostly separate, and inter-procedural optimizations can treat them as externally-linked (untouchable). I’m less familiar with assembly. but couldn’t processors expose instructions to enable or disable their JIT?

I imagine it’s not

easy* easy, because it requires every layer to cooperate, but if there’s demand I think it would be done.

IPv6 is in a similar situation where it requires widespread adoption, but I also suspect most people have issues with it and there isn’t much demand because NATs and whatever support for cellular networks has made it unnecessary.

diamondlovesyou · a year ago
> Why is cooperation unlikely? AFAIK it’s not too hard to make a compiler support a function attribute that says “do not optimize this function at all”

Compilers like Clang actually generate terrible code; it's expected that a sufficiently smart optimizer (of which LLVM is a member) will clean it up anyway, so Clang makes no attempt to generate good code. Rust is similar. For example, a simple for-loop's induction variable is stored/loaded to an alloca (ie stack) on every use, it isn't an SSA variable. So one of the first things in the optimization pipeline is to promote those to SSA registers/variables. Disabling that would cost a ton of perf just right there, nevermind the impact on instruction combining/value tracking/scalar evolution, and crypto is pretty perf sensitive after security.

BTW, Clang/LLVM already has such a function-level attribute, `optnone`, which was actually added to support LTO. But it's all or nothing; LLVM IR/Clang doesn't have the info needed to know what instructions are timing sensitive.

diamondlovesyou commented on High-speed 10Gbps full-mesh network based on USB4 for just $47.98   fangpenlin.com/posts/2024... · Posted by u/fangpenlin
Sweepi · 2 years ago
8 Zen4 cores dont beat 16 Zen2 cores in multicore. Either Geekbench 6 does not utilize all cores, or the 3950x setup is borked.
diamondlovesyou · 2 years ago
GB6 will use the Zen4's AVX512, which Zen2 doesn't support.
diamondlovesyou commented on Rust std fs slower than Python? No, it's hardware   xuanwo.io/2023/04-rust-st... · Posted by u/Pop_-
js2 · 2 years ago
Isn't the high startup cost what FSRM is intended to solve?

> With the new Zen3 CPUs, Fast Short REP MOV (FSRM) is finally added to AMD’s CPU functions analog to Intel’s X86_FEATURE_FSRM. Intel had already introduced this in 2017 with the Ice Lake Client microarchitecture. But now AMD is obviously using this feature to increase the performance of REP MOVSB for short and very short operations. This improvement applies to Intel for string lengths between 1 and 128 bytes and one can assume that AMD’s implementation will look the same for compatibility reasons.

https://www.igorslab.de/en/cracks-on-the-core-3-yet-the-5-gh...

diamondlovesyou · 2 years ago
Fast is relative here. These are microcoded instructions, which are generally terrible for latency: microcoded instructions don't get branch prediction benefits, nor OoO benefits (they lock the FE/scheduler while running). Small memcpy/moves are always latency bound, hence even if the HW supports "fast" rep store, you're better off not using them. L2 is wicked fast, and these copies are linear, so prediction will be good.

Note that for rep store to be better it must overcome the cost of the initial latency and then catch up to the 32byte vector copies, which yes generally have not-as-good-perf vs DRAM speed, but they aren't that bad either. Thus for small copies.... just don't use string store.

All this is not even considering non-temporal loads/stores; many larger copies would see better perf by not trashing the L2 cache, since the destination or source is often not inspected right after. String stores don't have a non-temporal option, so this has to be done with vectors.

diamondlovesyou commented on Rust std fs slower than Python? No, it's hardware   xuanwo.io/2023/04-rust-st... · Posted by u/Pop_-
diamondlovesyou · 2 years ago
AMD's string store is not like Intel's. Generally, you don't want to use it until you are past the CPU's L2 size (L3 is a victim cache), making ~2k WAY too small. Once past that point, it's profitable to use string store, and should run at "DRAM speed". But it has a high startup cost, hence 256bit vector loads/stores should be used until that threshold is met.
diamondlovesyou commented on Steam Deck OLED   store.steampowered.com/sa... · Posted by u/robbiet480
criddell · 2 years ago
I want a small, inexpensive gaming computer to connect to my TV and have been thinking about the Steam Deck or a mini pc like the Minisforum HX99G (Ryzen 9 6900HX). Would the two computers be roughly comparable?

I'm looking for something small because I don't have room for anything bigger. The Steam Deck is appealing because it doesn't seem very computer-y. What I want is a console that plays PC games. I've tried SteamLink between my desktop computer and AppleTV but it was a terrible experience.

Is there something better than the Steam Deck that isn't expensive (ie not more than $2000).

diamondlovesyou · 2 years ago
I have been very happy with my Minisforum Venus UM790, though I use it as a mobile computer since I can just throw it into my backpack. It's been great to have access to AVX512 on the go.
diamondlovesyou commented on Speed Up C++ Compilation   devtalk.blender.org/t/spe... · Posted by u/todsacerdoti
rewmie · 3 years ago
> strikes me as something of a language flaw that without pimpl any addition/removal/ modification of private member functions, or even renaming of private member variables triggers full recompilation of every source file that needs to use a particular class.

It is not a language flaw. C++ requires types to be complete when defining them because it needs to have access to their internal structure and layout to be in a position to apply all the optimizations that C++ is renowned for. Knowing this, at most it's a design tradeoff, and one where C++ came out winning.

For the rare cases where these irrelevant details are relevant, C++ also offers workarounds. The pimpl family of techniques is one of them, and type erasure techniques are also useful, and protocol classes with final implementations are clearly another one. Nevertheless, the fact that these techniques are far from being widely used demonstrates that there is zero need to implement them at the core language level.

diamondlovesyou · 3 years ago
> It is not a language flaw. C++ requires types to be complete when defining them because it needs to have access to their internal structure and layout to be in a position to apply all the optimizations that C++ is renowned for. Knowing this, at most it's a design tradeoff, and one where C++ came out winning.

This statement is incorrect. "Definition resolution" (my made up term for FE Stuff(TM) (not what I work on)) happens during the frontend compilation phase. Optimization is a backend phase, and we don't use source level info on type layout there. The FE does all that layout work and gives the BE an IR which uses explicit offsets.

C++ doesn't allow two phase lookup (at least originally); that's why definitions must precede uses.

diamondlovesyou commented on Speed Up C++ Compilation   devtalk.blender.org/t/spe... · Posted by u/todsacerdoti
jokoon · 3 years ago
I love C++, but compile time prevent me from enjoying it.

I would gladly use a new version of C++ that breaks compatibility but solve this problem.

This is the largest barrier for C++ right now.

diamondlovesyou · 3 years ago
The power of the optimizations available to C++ are what make it so fast (see how slow debug mode is vs -O2/etc), and what allow C++ to be fast in the face of common/easy-to-understand, but technically perf-hostile, patterns. Bit counting loops vs popcnt, auto-vectorization, DCE, RCE, CSE, CFG simplification, LTCG/LTO, and so on. These things let you write "high level" (to a point - there are some ways to do "high level" paradigms and absolutely eviscerate the compilers ability to optimize) code/algos and still get great hardware level performance. This is so much more important overall than the time it takes to compile your program, and even more so once you consider that often such programs are shipped once and then enter maintenance mode.

It doesn't really have anything to do with compatibility (not entirely, but the things that are the biggest issue to good optimization quality and are fixable are things that need a system-level rethinking on how hardware exceptions happen). It just isn't reasonable to expect developers to know how to optimize, and it doesn't scale.

u/diamondlovesyou

KarmaCake day239April 23, 2014
About
I work on compiler auto-vectorization and middle ends in general.

Contact me via email: dick at richard no-space c no-space diamond dot com

View Original