It's interesting that the roadmap of volt has been saying v1.0 is just around the corner for the past half year. The other roadmap items also don't change much.
It would be great if the roadmap contained realistic items. Once a user is burned by an unmet expectation he won't believe anything else on the website.
Are there any routers supported by OpenWrt that can handle 1Gbps WAN to LAN? My current router only pulls 150Mbps and I want to keep OpenWrt due to the amount of custom network configuration that has been done.
- use usb-tablet (<input type='tablet' bus='usb'/>) for much more convenient mouse input that does not lock to window. Initial setup may need to be done with usb mouse (<input type='mouse' bus='usb'/>)
All of the above need to be reflected in QEMU command line.
I've been using this setup for last half year without issues (mostly heavy compiling).
I'm looking forward porting this setup to 32-core Threadripper. Would be a hell of a beast that outperforms Apple HW that costs several times more.
Due to some reasons I couldn't use contact lenses in one eye for a couple of months. I switched to using contacts in single eye for that period, as I can't stand glasses for more than one hour due to very high myopia. It turns out, single contact has enough benefits that I didn't switch back to wearing two contact lenses after the issues with the eye went away. Instead I use single contact lens alternating between eyes for the last four years. Some observations:
- The issues with contact lenses became almost nonexistent. I almost never feel dryness in the eyes.
- Perhaps surprisingly, whenever I feel dryness in the eyes, it's always the eye without contact lens.
- It seems that the eyes have much much higher stamina now. They never feel tired regardless of how much I abuse them. I could look into screen all day without breaks and I wouldn't feel any issues as far as eyes are concerned.
- Since I have high myopia, using single contact gives my vision very high dynamic range. The eye without a contact is almost like a microscope.
- The potential wear of the cornea is reduced twice.
I can also attest that the brand of the contacts matters a lot. I remember several brands of contacts being really uncomfortable to use. Currently I wear 'Biofinity XR' if anyone cares. There were several other brands that I liked, but I don't remember them.
Any large project needs a build system with complex data structures to express all the dependencies just due to sheer amount of them. Add various types of source generation, tooling, non-trivial build steps and simple build systems quickly become infeasible.
It's possible to work around the restriction easily. This tool (https://github.com/p12tic/eagle-brd-merge) can move a single Eagle board around, so whenever you want to move a component outside the allowed window you simply move the board. You can panelize the boards without any board size restriction using that tool too.
It's possible to do automatically this by using a SIMD library such as libsimdpp (https://github.com/p12tic/libsimdpp). Everything is mostly abstracted away and you just write the SIMDified code once and add a CMake rule that builds the same file for several architectures, sets up dynamic dispatch and links everything together.
By saying single code path, I don't mean single instruction stream. libsimdpp, for example, supports building same code for different instruction sets, linking into the same executable and then dispatching dynamically. Doing this by hand would mean that either:
- lots of time is wasted creating slightly different versions of code. I'm talking about e.g. AVX vs. AVX2 for floating-point code not SSE2 vs. AVX.
- micro-optimization opportunities are wasted by only coding for major revisions of the instruction set
Even when optimal performance may only be achieved via completely different approaches, the SIMD wrappers are easier to use, because they present consistent interface. Any specialized instructions may be used by simply falling back to native intrinsics.
Thus I don't see much benefit of writing SIMD code without a wrapper. The only advantage is that it's harder to shoot oneself into the foot with naive use of these wrappers, e.g. if one doesn't actually look into the generated assembly code.
Though I must note in this case the SIMD wrapper has significant problems. Due certain design decisions the wrapper performs suboptimally on mixed float-integer code on AVX for example.
The property of AVX and AVX2 you mentioned actually helps having single code path. If the SIMD wrapper allows parameterization on vector width (most do that), you can simply increase vector width when compiling for AVX and that's it.
It's much better to use any of the numerous SIMD wrappers such as libsimdpp or Vc and get various benefits for free. It's possible to target everything from SSE and NEON to AVX512 with what is essentially a single code path.
https://web.archive.org/web/20180615121501/https://volt.ws/
https://web.archive.org/web/20181023093131/https://volt.ws/
It would be great if the roadmap contained realistic items. Once a user is burned by an unmet expectation he won't believe anything else on the website.