StreamDiffusion
rewrite
StreamDiffusion | rewrite | |
---|---|---|
4 | 24 | |
8,969 | 1,904 | |
- | 7.5% | |
9.6 | 9.9 | |
21 days ago | 6 days ago | |
Python | Java | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
StreamDiffusion
- FLaNK Weekly 31 December 2023
-
StreamDiffusion: Over 100fps Stable Diffusion on a 4090
Everyone does warmup before you measure. But measuring isn't always done right because we actually measure the GPU time only but some people naively use CPU time which is problematic because the process is asynchrenous. They have a few timing scripts though and I'm away from my GPU. There are some interesting things but they look like they know how to time. But it can also get confusing because is it considering batches or not. Some works do batch some do single. Only problem is when it isn't communicated correctly or left ambiguous.
Their paper is ambiguous unfortunately. Abstract, intro, and conclusion suggests single image by motivating with sequential generation (specifically mentioning metaverse). Experiment section says
> We note that we evaluate the throughput mainly via the average inference time per image through processing 100 images.
That implies batch along with their name Stream Batch...
Looking at the code I'm a bit confused. I'm away from my GPU so can't run. Maybe someone can let me know? This block[0] measures correctly but is using a downloaded image? Then just opens the image in the preprocess? (multi looks identical) This block[1] is using CPU? But running CPU. (there's another like this)
So I'm quite a bit confused tbh.
[0] https://github.com/cumulo-autumn/StreamDiffusion/blob/03e2a7...
[1] https://github.com/cumulo-autumn/StreamDiffusion/blob/03e2a7...
- StreamDiffusion: A Pipeline-Level Solution for Real-Time Interactive Generation
rewrite
- FLaNK Weekly 31 December 2023
- OpenRewrite – Automated mass refactoring of source code
-
AST-grep(sg) is a CLI tool for code structural search, lint, and rewriting
If you're into this sort of thing, there's OpenRewrite[1] for the Java ecosystem.
[1] https://docs.openrewrite.org/
-
What's New in Spring Framework 6.1
> Spring has gotten so bloated.
I'd call Spring feature-rich than bloated. You can always shed weight that you don't want to carry.
> Plus there's multiple ways of doing the same thing. e.g. JPA, spring-data.
That's because there are different ways to solve a problem. Someone may want an ORM-based approach to connect to the database; they can choose spring-data-jpa. Someone may want to use JDBC with a light abstraction on top of it; they can choose spring-data-jdbc. It's all about choices and right tradeoffs and Spring offers plenty of them.
> they don't provide easy upgrade paths between majors versions
That's not my experience. I've been happily upgrading 2.x.x versions and plan to upgrade to 3.2.x when it is ready. But depending on the codebase, I admit it can be painful. Projects like OpenRewrite[1] might help here.
> and they stop updating vulnerabilities on older major versions.
This is not news. They want you to pay for extended support if you need it.
> No docs on migration.
They do maintain migration docs on GitHub wiki which are a lot more detailed than their blog posts on migration. Here's the latest one to upgrade from Spring Boot 2 to 3: https://github.com/spring-projects/spring-boot/wiki/Spring-B...
[1]: https://github.com/openrewrite/rewrite
-
We already have Spring 2.1.3, Is SpringBoot 3 worth learning.
The issue you may run into when migrating from Spring Boot 2.x to 3.x is the JEE namespace renames. Migrating code from 8 to 17 in my experience hasn't been all that difficult. In most projects, there are no changes to make. However, with the namespace change, you'll probably have to do some planning and testing. If you are migrating a lot of projects, check out Open Rewrite, it may help automate a lot of these upgrades (for both 8 to 17 and Spring Boot versions).
-
Why wouldn't somebody change their version?
Couldn't OpenRewrite (https://docs.openrewrite.org) do a big part of this manual work?
-
Any ideas on how to automate upgrade of legacy Spring Framework/Spring Boot repositories?
Openrewrite would probably be a big help, see https://docs.openrewrite.org
-
what is your favorite programming trick/tool that not many People know about?
In a similar vein there is OpenRewrite which is an open-source project that works in a similar way. It also has a lot of great refactorings already built in, like doing all the grunt work for migrating to JUnit 5, or replacing string concatenation in SLF4J log calls with parameterized formatting.
-
Refactoring giant codebase
seems a case for https://docs.openrewrite.org/
-
What are your thoughts on Spring in 2023?
https://github.com/openrewrite/rewrite might help