|
Oh the horror!!!!!
Jeremy Falcon
|
|
|
|
|
Wroooong! This is fake news and name calling designed to spread lies and demoralization. The alternative fact is that it is not even called Death Star, but Battle Station. It is all lies of the rebel media. Sad!
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Indeed! There is evidence[^] that it was not destroyed at all. It is a little battered and has been parked in orbit around Saturn.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
IF you'd been paying attention at 01:02:37 you would know the equator of the Death Star was the location for the landing bays. I thought everyone knew that.
veni bibi saltavi
|
|
|
|
|
Well, it's not an equator at all...
|
|
|
|
|
Someone! Anyone! Please Explain to me why this matters the least bit?
Did someone run out of dancing angels to count on a pinhead?
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
It was pretty obviously not the equatorial trench -- that thing must be a mile wide.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
The matrix4x4, plane and quaternion types are alright. Sort of. Except that they automatically encourage AoS layout. But the general purpose Vector and Vector<t> (why does the linkifier lowercase my T?) are horrible. At a first glance, those pages seem a little short (for SIMD anyway). That's because there are almost no functions to list.
But when you look at what's actually missing, it gets worse. A lot worse.
Before anyone comments "it's designed that way for portability" - yes, maybe, but that is no excuse for designing something that's useless on all architectures. There are ways they could have given us something that isn't useless, one suggestion is at the bottom.
No width-converting casts!
That's right, you can only reinterpret cast a vector (which is certainly a necessary operation, though it is made more necessary than necessary(?) here because they made signedness part of the type). Certainly, it is preferred to not widen your data, for obvious reasons: if you make the data twice as wide, half as much of it fits in a vector, half as much gets done per instruction. But often there's just no avoiding it, especially with 8 bit data, which you often have to process in 16-bit fixed-point, more about that later.
There are no shuffles either, which could have been used to "fake" width conversions, but are generally necessary for almost any SIMD task that isn't strictly vertical. Now I get it, having both shuffles and variable-with vectors is really hard, probably impossible in general. So here's the solution: don't have variable width vectors. Just let me pick 128 or 256 when I write the code, yes it won't auto-upgrade to a bigger width on newer platforms but it is necessary in order to have any code in the first place. There's no point in having fancy future-compatible things if you can't use them.
Also that means there can be no pshufb tricks, which I admit aren't actually common.. but when you need it, you need it. You can forget about compacting an array after filtering it, for example. Actually you can't even do the "extract mask" part of that technique.
No special instructions, with "special" meaning "anything that isn't just like repeating a C# operator for a bunch of elements". Ok, there is ConditionalSelect. But where is Multiply High? Add with Saturation? Sum of Absolute Differences? Mask of Sbyte Signs? Mask of float signs? Multiply and Add Packed Signed and Unsigned Bytes? Average? Approximate Reciprocal Square Root? The list goes on.
Many of these are useful in part to avoid widening - eg I might have (with a bad conscience) simulated a 16 bit multiply-high (which is an extremely common operation, a lot of SIMD code does fixed-point arithmetic) by widening to 32bit and using a "normal" 32x32 multiply (ie vpmulld - which has extra bad throughput on top of handling half the elements that a 16bit highmul would), but I can't even do that because .. did I mention no width-converting casts? So what am I going to do, waste half of my memory throughput on padding? What if the source format inherently doesn't have it, write a non-SIMD loop to convert? All that, remember, just to enable code that is already severely sub-standard.
Some operations, such as average or add-with-saturation, can be implemented if you really need them - but in a way that thoroughly sucks, both for code-clarity and performance, all while there is a nice fast instruction to do it that could have had a nice clear intrinsic function paired with it.
Reasonable support for fixed-point arithmetic and saturation are crucial, they are everywhere in multimedia computations, but System.Numerics.Vectors has essentially no support for them.
It gets weirder: there aren't even bit-shifts. This one is just really random. Yes, per-lane-variable shifts are an AVX2 thing (but so what, they allow a bunch more stuff that has to be emulated), but shift-by-scalar should definitely exist. "Just write a multiplication or division" - yes well, that's just obfuscating the code. Plus, signed right shift works differently than signed division.
Meanwhile it's legal to request operations that cannot be implemented in a reasonable way, such as regular 8x8 or 64x64 multiplication. That just doesn't exist in SSE up through AVX2. I haven't looked at how it's emulated, but it can't be anything nice, because there is no nice way to do it. And then there are integer divisions and square roots.. The API falls victim to its overly orthogonality - which normally would be a nice property, but if the instruction set doesn't offer it, offering it in the API is not "being nice and filling the hole", it's setting a performance trap for unsuspecting programmers who aren't used to the peculiarities of the instruction set.
Here's what you can do with System.Numerics.Vectors:
- compositions of nice clean purely-vertical maps
- simple reductions
- combinations of the above
Which is the sort of thing that the compiler could do (it doesn't, but it could, offline compilers are doing it - inb4 "JIT latency"), and will do* if you quickly make a C(++) dll project on the side and PInvoke that. As a bonus you can then also write proper SIMD code the way god Intel intended.
*: if you're using a new enough MSVC (so not 2010 or older), or if you use Clang/GCC/ICC/whatever, anything that has auto-vectorization.
How should it work instead of this mess? My first thought is, don't invent anything new, just put in the widely accepted sets of SIMD intrinsics for SSE through AVX2 under an X64 class, and the NEON intrinsics under an ARM class (and whatever else, though I don't imagine many would care about IA64 intrinsics for example). Add some nice feature-level checks too, instead of letting everyone always re-implement them on top of CPUID. This has problems (mainly readability, code with the usual SSE intrinsics looks uglier than the corresponding assembly code) and even a few "missing" bits itself, but they are at least problems that the community is used to and can deal with, not huge deal breakers.
Maybe there are better (better at what? you decide) ways to fix the System.Numerics.Vectors mess, so, let's discuss it.
I have probably forgotten things or made mistakes so I'll probably make some edits
|
|
|
|
|
imho, another post with useful technical information that could be moved, or copied, to another forum so the content doesn't drown in the daily tidal surge that inundates the lounge. Note: what I just said is not intended to disparage Harold, or, his post, or, the Lounge.
cheers, Bill
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
Well I don't know. I sort of get the feeling that almost no one cares about this problem in the first place
|
|
|
|
|
WHERE IS MY APPLE
Something different... And not, we are not looking for your lost iPhone...
Before you three - covered - crates of fruit. One full of oranges, the second full of apples and the third a mix of both.
All of the crates are labeled - 'Apple', 'Orange' and 'Mix' - but all of them labeled wrongly...
You can pick one fruit from one crate - blindfolded, so you could not see the rest, and you have to say what crate contains what fruit...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
modified 25-Jan-17 15:07pm.
|
|
|
|
|
bananas.
Kornfeld Eliyahu Peter wrote: Before you free
And unless you have a lifp, I fink you meant three.
Marc
|
|
|
|
|
I would add kiwi too... And juice from red grapefruit...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Because all the labels are wrong, the label tells you what the box can contain:
"Apples" contains Oranges, or is mixed.
"Oranges" contains Apples, or is mixed
"Mixed" contains Just Oranges or Apples.
Pick one fruit blindfold from "Mixed" - you know know which fruit it contains.
If it's an Apple, then "Apples" contains Oranges, and Oranges is mixed.
If it's an Orange, then "Apples" is mixed, and "Oranges" contains apples.
If you like, a truth table with show it:
Legend> A O M
Pick v
AAA X
AAO M A O
AOA X
AOO X
OAA O M A
OAO M A O
OOA O M A
OOO X Where "X" indicates an impossible combination.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: the label tells you what the box can contain:
Yup, I started to go down the path of creating a solution tree based on what was picked and knowing the boxes are all mislabeled, but my attention span failed me.
Marc
|
|
|
|
|
That's what happens at our age, I understand..
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I'm sorry, what was the question again?
|
|
|
|
|
Can you type that a bit louder? I didn't quite catch it.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Oops! Hit the wrong "reply" button...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I have a gun. I'm not going to let you blindfold me, and I'll pick from as many goddamn crates as I want. Any more questions?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Before you are three targets, marked "commie", "jihadist", and "liberal"... oh, you shot all three already, OK.
|
|
|
|
|
What kind of gun?
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Probably not a water pistol.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Probably?
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
A .45 because they don't make a .46.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|