Yeah. I don’t think dual cards is a great solution as I don’t think they can both be made to work on the same job at the same time, but maybe if you were generating many images it would make sense.
I don’t know, but maybe somebody else has experience.
I’ve tried to find comparison data on performance between AMD Vs Nvidia and I see lots of people saying what you’re saying, but I can never find numbers. Do you know of any?
If a card is less than half price, maybe I don’t mind it’s lower performance. It all depends on how much lower.
Also, is the same true under Linux?
So you could buy 2xAMD 24GB and a good power supply to power them for a 4090.
It’s the training that’s the issue more than inferring.
Soft forks try to maintain code compatible so changes can apply to both code bases. Normally done when there’s hope of a future merging of the code lines. They rarely work, as eventually thing get hard.
Migration is seamless. Uninstall one binary and install the other.
Part of it might be that I’m often having similar arguments with the team I run about introducing dependencies.
Engineers have a tendency to want to use the perfect tool for a job at the expense of other concerns. It could be ease of maintenance, availability of the skill-set, user experience, or whatever. If there’s pushback it’s normally that they are putting their own priorities above other people’s equally valid concerns.
Often I’m telling people to step-back. Stop pushing, listen to the resistance and learn from it. Maybe I’m on a bit of a crusade when I see similar situations in open-source.
I think for python tooling the choice is Python Vs Rust. C isn’t in the mix either.
people like and want to program in rust
I think there’s a survivor bias going on here. Those that have tried rust and stuck with it, they also like it. Far more people in the python community haven’t tried it, or have and not stuck with it. I like and want to program Haskell. I’m not going to write python tools in it because the community won’t appreciate it.
Tools should be maintained by those that use them. Python doesn’t want to rely on the portion of the venn diagram that are rust and python users because that pool of people is much smaller.
Those languages bring different things though:
Python is the language the tool is for
C is the implementation language of Python and is always going to be there.
Cython is a very similar language to Python and designed to be very familiar to Python writers.
Fortran is the language that BLAS and similar libraries were historically implemented in since the 70s. Nobody in the python community has to write Fortran today. Those libraries are wrapped.
Rust is none of the above. Bringing it into the mix adds a new barrier.
I don’t think it’s a dream of “everything in python”, but “python tools for python development”. It means users of the language can contribute to the tooling.
…and people worry about the name of a git branch.
Op was listing different Lsp servers for things like jedi, pyright, etc. All of those things should really integrate with a single server.
Sounds like things are going very wrong in lsp land. The point of a language server is to support lots of types of tools through an abstracted server. Not to have one server per tool.
Otherwise, just use fly-checker. It can even get information from multiple tools at once.
Oh, “incident post-mortem” was ambiguous. I read “Incident that happened after death” not “analysis after incident”.
I thought OP had a necrophiliac blowjob fantasy.
I have a lot of respect for this project. I lurk on the discussion forum and issues and I’ve always seen mature discussion even though the project was born out of issues which could have been quite emotive.
It’s also a lot nicer to run than any other git forge that I’ve had experience with.
Do you think a style guide is enough for an open source code base? Contributions could be coming from lots of directions, and the code review process to enforce a style guide is going to be a lot of work. Even rejecting something takes time.
Furthermore there are many changes to NumPy internals, including continuing to migrate code from C to C++, that will make it easier to improve and maintain NumPy in the future.
I realise that C can be rather low level a lot of the time, but I’m not sure I’d pick C++ to help keep things easy to maintain. It opens up a Pandora’s box of possibilities.
Does it have higher-order functions? Yes, therefore you can use it to do functional programming.
Everything else is syntactic sugar.
…or the research is flawed. Gender identity was gained from social media accounts. So maybe it’s a general bias against social media users (half joking).
Ewwww! Hard pass.
I’ll keep with the old way thanks. Sure, pytorch installs are a pain in the butt, but that’s why I’m pretty sure a pre-packaged version is not going to make life easier. I also despise electron apps.
I realise as somebody who isn’t afraid of a little command line Linux, I’m not the target audience. However, is anyone who is using diffusion models right now… especially someone who isn’t scared off by noodles… asking for this? The software is for experimenters who enjoy building their own flows. It’s mode of operation is “some assembly required”.