> If traders have to be covered with the actual stock, would that mean they can only short Foo shares up to the amount they own? Surely that's equivalent to just selling your holdings?
I had selling a call option in mind.
2,917 karma · joined April 21, 2019
I had selling a call option in mind.
Why would you completely disallow shorting ?
I'd think that in such a framework, shorting would just need to become a longer term bet. So one could offer something like 2,5,10 year LEAPs, but restrict their trading to a window of 1 week per year (e.g. one can trade derivatives as much as one wants, but only during week X, which is the week when all derivatives expire, and all derivatives are long term).
Also for options, one would need to always require traders to be covered with the actual stock.
Lol that's me.
I also use it to set timers while cooking, and play music (I think the sound of Alexa is quite good). But that's basically it.
A wireless speaker that can set timers / arams, and maybe control music, would allow me to replace Alexa. Is there something like this ?
They say "We are sorry", give you some free credit, and that's it ?
We have a gitlab server, and connecting requires being on VPN, which requires 2FA, and then ssh, which requires your keys to be properly set up.
And honestly moving to these tools from slack, confluence, etc. has been awesome.
Zulip threading model is great. So much better than slack.
And using markdown and jupyter notebooks for documentation on gitlab? Damn awesome.
Not that this matters because your argument is flawed.
The claim that CUDA is not worth using because it lacks portability, only holds, if there is hardware worth using that's not supported by CUDA.
The only GPUs worth buying for compute are from nvidia and support CUDA, so your claim isn't true.
The only thing you achieve today by not using CUDA is paying a huge price in development quality for portability that you can't use.
The startup cemetery is filled with companies that made this trade-off and picked OpenCL just in case they wanted to use non-nvidia hardware. They were all killed by the velocity of their competitors that were using CUDA to deliver better products that payed the bills.
The only people for which it might make sense to avoid CUDA are "non-professionals" (hobbyist, etc.). If you only want to use OpenCL to "learn OpenCL", then OpenCL is the right choice. But if you want to make money, then CUDA was the right choice 15 years ago and still is the right choice today.
If that makes you angry, direct your anger properly. It isn't NVIDIA's fault that CUDA is really good. It is however, AMD's, Intel's, Apple's, Qualcomm, ARM's... fault that everything else _sucks hard_. Being angry at nvidia for delivering good products is just stupid. Its the other companies fault that they can't seem to be able to get their sh* together when it comes to GPU computing.
See: https://www.anandtech.com/show/15746/opencl-30-announced-hit...
This was also extensively discussed here in HNs. You might be able to find that thread, was really interesting.
The "always inline" problem is smaller in Rust, because it does Thin LTO by default, compiles partially to bit-code, that can be partially inlined if necessary, etc. So essentially the Rust toolchain is a bit better at inlining when its profitable than C and C++ toolchains "by default" (you can tune C and C++ toolchains like clang to be as good as Rust).
In C and C++, macros are generally frowned upon, not because of this compile-time issues, but rather because they are dangerous, tricky, non-hygienic, powerful usage requires complex patterns, their interaction with header files and PCHs, etc.
Rust macros are awesome, super useful, widely used, etc. So people end up using them a lot, and this is by design, not a flaw of the language. This ends up resulting in a lot of duplicated code being expanded, and that leads to the problem that you mention, but much worse, because there are just many more macros in Rust.
This kind of applies to templates / traits as well. There are many C++ that don't write templates, but all Rust programmers use generics because they are great. Rust can pre-compile generics, so the cost of this is not as bad as for C++ where the same generic might be instantiated by multiple TUs. But still, just by the fact that they are more widely used, the size of the problem grows.
Even if one were to encrypt all connections, these will probably need to be decrypted on the GPU for processing.
Rust translation units do not have the header file problem (so the frontend does less work), and they are also much larger in terms of definitions, often spawning multiple files, so there is more for the backend to do per translation unit.
The consequence is that Rust spends more time on LLVM relatively speaking than C and C++.
The solution to this problem in Rust is naively simple: write smaller translation units.
Rust programmers just want to structure their code however their want, and still have good compile-times. Which is kind of the opposite of how C and C++ programmers typically structure their code in the largests projects, because they value faster compile-times over that kind of "ergonomics"/code organization.
Why didn't AMD do this as well? I thought AMD was strong on supporting open source.
So I suppose you still used OpenCL for AMD and Intel hardware because that worked well there? That is, OpenCL only worked poorly on nvidia hardware?
If that's the case, I wonder what's your take on OpenCL 3.0 reverting all OpenCL > 1.2 features, such that OpenCL 3 is essentially OpenCL 1.2. The reason given by Khronos is that _nobody_ was implementing these features anyways. Yet your story sounds like AMD had great support for OpenCL newer features, and only nvidia's support was poor, kind of contradicting Khronos themselves.
Maybe you meant that nvidia has poor support for OpenCL 1 ?
No, you don't _need_ to use CUDA for GPU programming, you can use OpenCL or Vulkan or probably even PHP instead.
I do, however, _want_ to use the best programming language for the task at hand. If that task is GPU programming, CUDA is the best language I know for that, much better than SyCL, OpenCL, Vulkan / OpenGL + shaders, etc.
If these other technologies would be better, I would use them instead.
There aren't any.
LLVM can process multiple codegen units in parallel already, and many frontends split TUs into multiple codegen units.
Not sure how much money they made selling their stake on the company, but if Wikipedia's valuation for Acorn and ARM are correct, can't be more than a couple of million dollars.
Those shares would be worth many billions of dollars today.
---
Why do you think the brits have anything to do with anything?
If ARM ends up being bought by NVIDIA, that would actually be this Hermann Hauser's guy fault for selling ARM for pocket change. Complaining that their buyer's buyer's buyer now wants to make money with those shares by selling them to the highest bidder is sad. If ARM was so important to him, then maybe they shouldn't have sold their stake on it in the first place... Making a show about it now is like complaining that your ex that you dumped now has a new boyfriend.
There are probably many HN features nobody knows about because the UI doesn't expose them.
Sure, but it is not like Intel is going to fab AMD and nvidia chips, so they need other competitors, like Samsung, and that's what they are using.
Or selling GFX cards..
I was surprised over the difference 320 Hz monitors make according to them.