> What the VLIW of Itanium needed and never really got was proper compiler support.
This is kinda under-selling it. The fundamental problem with statically-scheduled VLIW machines like Itanium is it puts all of the complexity in the compiler. Unfortunately it turns out it's just really hard to make a good static scheduler!
In contrast, dynamically-scheduled out-of-order superscalar machines work great but put all the complexity in silicon. The transistor overhead was expensive back in the day, so statically-scheduled VLIWs seemed like a good idea.
What happened was that static scheduling stayed really hard while the transistor overhead for dynamic scheduling became irrelevantly cheap. "Throw more hardware at it" won handily over "Make better software".
No, VLIW is even worse than this. Describing it as a compiler problem undersells the issue. VLIW is not tractable for a multitasking / multi tenant system due to cache residency issues. The compiler cannot efficiently schedule instructions without knowing what is in cache. But, it can’t know what’s going to be in cache if it doesn’t know what’s occupying the adjacent task time slices. Add virtualization and it’s a disaster.
If it's pure TFLOPs you're after, you do want a more or less statically scheduled GPU. But for CPU workloads, even the low-power efficiency cores in phones these days are out of order, and the size of reorder buffers in high-performance CPU cores keeps growing. If you try to run a CPU workload on GPU-like hardware, you'll just get pitifully low utilization.
So it's clearly true that the transistor overhead of dynamic scheduling is cheap compared to the (as-yet unsurmounted) cost of doing static scheduling for software that doesn't lend itself to that approach. But it's probably also true that dynamic scheduling is expensive compared to ALUs, or else we'd see more GPU-like architectures using dynamic scheduling to broaden the range of workloads they can run with competitive performance. Instead, it appears the most successful GPU company largely just keeps throwing ALUs at the problem.
I think OP meant "transistor count overhead" and that's true. There are bazillions of transistors available now. It does take a lot of power, and returns are diminishing, but there are still returns, even more so than just increasing core count. Overall what matters is performance per watt, and that's still going up.
I'm intrigued. Can you expand more on this? Why does it work? I guess because the hail is rarely coming straight-on at the holes and instead makes more glancing blows off the wire?
In any case I think it's a perfect example of a good hack. Original out-of-the-box thinking producing an effective but unconventional solution. Chapeau bas!
i saw chicken wire used for something unknown to me on top of old 1800s greenhouses in France. it was not used for hail because it was resting directly on top of glass. i do not know what it was there for.
but hail and flying debris i got past few years is so big and so frequent that im not sure chicken wire will do the job.
a lot of gardeners use shading cloth for lowering sun light intensity. but that is not always enough to withstand hail.
A lot of times there is multiple pieces of hail stuck in one hole. some just bounce off.
i have PV on roof and not had issue with that. but i had few broken glass pieces of greenhouse glass. even tho it is on same property. it is glass-glass bifacial, i did not do it for back light but for longevity, i saw too many plastic backing tear off, or delaminated or how to call it. so i did not want that. and im not sure if that is also factor in not having broken PV.
doing it on huge PV areas should atleast be by my feeling too much of hassle, investment.
But some people mentioned in other comments small arrays of, if i remember correctly, 5kWp. so that is roughly area im doing it on. so in those small arrays it can be done manually.
I am not entirely convinced that capitalism is the best system for producing software, especially established "infrastructure" software like OSes, web browsers, office suites, etc.
I'm open to the idea, and recognize there are problems with non-commercial software, too. But the critical difference between software and physical commodities is that replication of software, once written, has a marginal cost approaching zero.
I suspect that this difference significantly changes the calculus.
My personal feeling is we should really think outside the box here. I like some sort of hybrid system with government-funded software bureaus producing FOSS code to replicate successful and important "infrastructure" commercial products after five to ten years or so. People get cutting-edge software created by the market, and exploitative rent seeking on critical software is minimized.
> The goal of any advertising service is to match people with relevant ads
The goal of any advertising service is fully automated population-scale digital pimping, with an extremely sophisticated matchmaking service (backed by all that data) as a value-add.
They put your ass on the RTB street to turn tricks. You get mindfucked by--and maybe catch some viruses from--any John who wants to take a crack at you. In return, you get this nice cheap TV/Youtube/Gmail/article.
> Chrome is developed by the same company whose core business is to collect as much data about me as possible.
Let's be more precise: Google's core business is pimping you out to any John who wants to mindfuck you, and selling a fantastically sophisticated matchmaking service on top, to which all that data is instrumental.
An alternative headline might be, "Hoes grow wary of pimpmobile's 'privacy' mode -- Pimp adds Military Grade Encryption(tm) to reassure bitches that 'nah baby, I really love you'"
> loads of nooks and crannies of SAT encodings that gave invaluable speedups in specific contexts
This is such an incredibly important observation it bears repeating. You're also not the first to make it (e.g. "If the final goal is the practical solving of hard real world problems and not only to make solvers overcome inappropriate encodings by rediscovering in the CNF formulas some deductions that are obvious in the original problem, then a careful encoding is crucial and must be considered as a third type of contribution beside solvers and benchmarks in the challenges organized for SAT." [0]), which makes it even more frustrating that we still haven't really made much progress there.
I have worked fairly extensively with SAT and SMT solvers and the "design space exploration" of how best, exactly, to transform your problem into gates or CNF is a maddening time-sink with do-or-die implications. If you get it wrong, the solver will never terminate.
How long should you let the solver run before bailing out and trying a new approach? How do you systematically explore the design space when you're not sure if your problem is "difficult" enough to demand a 24h timeout or if it "ought to be solved" within a 6h timeout? Should I use one-hot encodings everywhere? Is XOR a problem? Maybe a different solver will be able to solve it? Can some re-jiggering with "fraig","strash", etc. voodoo in ABC give me better/more consistent/more solve-able queries?
It goes on and on. The lack of established or at least well-known design patterns for encoding a problem into SAT queries makes it difficult to employ SAT solvers in practice. It's mostly trial by error with limited, very delayed, frequently non-existent feedback. Further, the heuristic nature of SAT solvers makes it a crapshoot to get consistent performance on varied problems, even using the same encoding techniques.
With that said, here's some advice I wish I'd gotten when I started working with SAT:
- The most correlated variable with solver time is problem size.
- More simpler SAT queries is way better than fewer bigger SAT queries. If at all possible, figure out a way to break one giant SAT query into a composition of multiple smaller SAT queries.
- However, simpler, but bigger (more gates) logic often works better than small but fancy complicated logic, especially if you can avoid XOR. Use ripple-carry or carry-select adders, not parallel prefix adders.
- One-hot and unary encodings are worth a try. But they're not always better.
- If you have some non-standard component in your problem, like a cardinality constraint, look for bespoke SAT encodings for that component first, before designing your own. Indeed, for cardinality constraints specifically, you should probably use the design presented by Bailleux and Boufkhad in "Efficient CNF Encoding of Boolean Cardinality Constraints"[0].
- Most (all?) solvers ship with a terrible malloc() implementation. Recompile your solver with Google's gperftools TCMalloc for a significant speedup.
- Throw hardware at the problem. Multiple fast (in a single thread, don't care about total throughput) high-cache CPUs in a cluster can help explore the design space faster, and can be used at solving time to approach the problem from different angles (i.e. different random seed) and with different techniques (i.e. varying solver parameters). You can't easily parallelize SAT, but you can easily run SAT in parallel.
- Try a different level of abstraction. Do you have a bit-blasted SAT problem? Try encoding it in SMT. Do you have an SMT problem? Try bit-blasting it to a SAT problem.
- Optimizing your problem with Alan Mishchenko's excellent ABC can make an intractable problem tractable. It can also make a tractable problem intractable. It's worth fiddling with it, if you've no other recourse. Some command sequences I've found to work well are:
Of course you are. You're rich.
reply