CefSharp VS pytorch-lightning

The Fullscreen Chromium (cefsharp) based Web-Browser ignores optionally user input like Mouse clicks, and is optionally always in the foreground (Force-Top-Most), so it can be used for any situation.

Just as a background: I'm working on a façade for the CefSharp utility. This utility requires the programmer to initialize and terminate it in the same thread, once-per-process. My current implementation uses a lazy initialization algorithm requiring inter-thread communication. But the possibility of AppDomains arising or passing away complicates the algorithm by requiring threads to potentially signal one another across AppDomain boundaries. It would be easier to just let the threads communicate without worrying about which AppDomain they belonged to.

I dont want to state the obvious but of course there is CefSharp .. But of course thats pretty heavy duty as you end shipping a headless version of Chrome in your app, but it can do anything a browser can do (of course it can, its Chrome), including exectuting a JavaScript string on the fly and getting a response. Because its Chrome you evenn have access the the dev tool and everything like that. But the other suggestions might be better suited as they might be more lightweight.

Two options: Either use an embedded browser you can control programmatically like CefSharp (https://cefsharp.github.io/) or spawn a real browser and use sendkeys() to control the browser by emulating user input.

Chrome Runtime discussion in CefSharp repository.

https://github.com/cefsharp/CefSharp/ if i spiked your intrigue

CefSharp

I always use https://cefsharp.github.io/

https://see.stanford.edu/Course/CS229 https://lightning.ai/ https://www.youtube.com/watch?v=00s9ireCnCw&t=57s https://towardsdatascience.com/

I've been wondering on what is the recommended method of saving logits/activations using PyTorch Lightning. I've looked at Callbacks, Loggers and ModelHooks but none of the use-cases seem to be for this kind of activity (even if I were to create my own custom variants of each utility). The ModelCheckpoint Callback in its utility makes me feel like custom Callbacks would be the way to go but I'm not quite sure. This closed GitHub issue does address my issue to some extent.

Our codebase for the diffusion models builds heavily on OpenAI's ADM codebase , lucidrains, Stable Diffusion, Lightning and Hugging Face. Thanks for open-sourcing!

For lightweight use, pytorch-lightning is too heavy, and its source code will be very difficult for beginners to read, at least for me.

For the A100 GPU, theoretical performance is the same for FP16/BF16 and both rely on the same number of bits, meaning memory should be the same. However since it's quite newly added to PyTorch, performance seems to still be dependent on underlying operators used (pytorch lightning debugging in progress here).