leeter

Can and have seen agile teams just create user stories for this. With estimates and acceptance criteria (yes having your people pass a quiz can be acceptance criteria). They even did an end of sprint demo where they had to present (without a deck) on the concepts of what they learned and answer questions.

Doesn't matter IIRC, most employers requires their employees to sign an agreement saying that anything they come up with during the term of their employment is owned by the employer unless the employer gives up rights explicitly. This is to prevent someone from getting "The next big thing" then running away to start a company for it even though their employer was interested.

IANAL but my reading of the situation would be that apple has a better claim on his IP than the tactic they're taking. All they'd have to do is prove that the idea was formulated at apple and they never signed it over to him. My understanding of Cali law (albeit likely very flawed) is that this suit as written is not supported by law.

As much as Microsoft would love to kill 32bit windows, 16bit line of business apps are sadly still a thing in some large companies. Companies that may not have the source of or cannot for a variety of reasons port the code to 32bit or 64bit. Because 32bit windows can still run 16bit apps it will continue to live on in the consumer and end user space. But as far as I know windows server 32bit does exist but is not licensed such that it can be used in production.

As best I can tell Intel kinda painted themselves into a corner with their 14nm+++ process. It produces really high quality parts (no surprise) but that also means that there is now an expectation of super high clocks on the intel side. That's not realistic however and I highly doubt their 10nm can currently match their 14nm+++ process on clocks (yet). It looks like Intel is thus focusing 10nm on areas where clocks more representative of a new node won't be an issue: server and mobile.

I'll be honest and say I'm very curious to see how intel tries to escape this trap they've set for themselves. Unless we see rapid gains in the 10nm process quality up into the 4.5+ GHz range I wouldn't expect to see 10nm desktop parts anytime soon.

> The fact that TypeScript wasn't created to solve a big issue internally at Microsoft

AFAIK it was, the issue was the poor quality of Javascript development they were having and their inability to really get good tooling and static analysis. Then it kind of exploded as other people said "That's cool" and they then pushed it out as open source so that if they did need to let it go it wouldn't be totally dead in the water.

I had a friend that noticed some really nasty vulns in his college's software (passwords in plaintext in the page, and the reset question and answer). I coached him how to very carefully report them and he had some help from family. But given that the uni takes federal funding he could have easily landed a federal felony for just reporting, and all he did was do view source on the page.

Good to know I was assuming they'd run a bit hotter. That will actually make the memory situation worse though in many regards.

So at a 225w TDP I'd guess that part is going to be clocked in the 1.2 -1.5GHz range. Definitely a specialist part IMO because with only 8 channels of memory that's 1 channel per eight cores which is not a ton of bandwidth. So for workloads that largely stay in the (I assume) ample L3/L2 caches that part will rock. But for anything that needs a lot of bandwidth spread across cores (databases come to mind) it will probably struggle where the higher clocking 24 core or 32 core parts will probably chug on fine. This oddly seems like a case where the 48 core may still be a better buy even for similar workloads due to higher base clocks.

Just my two cents.

I believe they tried, but it basically never made it out of committee as it's basically the same as banning people from using a highlighter on a book. It became very very clear that not only was it not enforceable but trying to go after the people supplying the adblocker would run into serious human rights issues.

AFAIK every browser but IE11 supports the modern basic grid syntax. Edge has supported the new syntax since Edge 16 which is old enough to be widely deployed in enterprise now. So as far as I'm concerned that's the "Vast majority of browsers" and for static grids I just use the old syntax as a fallback for IE11

https://caniuse.com/#feat=css-grid

There are IIRC a few minor exceptions, but those are for smaller communities just out of Area 51 AFAIK and those still apply to users that have shown extensive involvement in those communities. That said those users still have more than 1 rep in all cases AFAIK.

I updated my post with their comment, they may not be directly going through SEDE as there is an API that can be used. I know there is a bot called charcoal that sniffs out bad posts etc and auto reports them for example that uses the API.

I know that would likely be the main entry point and who found it. I reviewed that chat logs which are public and they just said they found it. As far as I know this isn't exactly hard information to find as you could just parse the moderator listings if you needed to.

This was their post for context: "API reports is_employee as False, but the user is not on mod lists, so... ?"

Stack Exchange data Explorer (SEDE) has been around for quite awhile. The user table contains flags for this. Who mods are has never been hidden. The user in question drew attention by having 1 rep and having CM level privilege on 173 sites. They also engaged in a pattern of behavior that didn't fit with that level of privilege.

https://data.stackexchange.com/

Crap like this is why I won't interview with a few larger companies and are a major turn off when smaller ones pull this garbage. I'm one of the people that when you try to quiz me my mind blanks. I hate whiteboard programming and prefer solutioning instead. If you want to see code I have a github I can send you. Or you can send me a programming challenge I can complete on my own time. Things like this have actually led me to basically tell at least one large company to cease and desist all recruitment efforts with me.

My guess? Because they aren't linking to it.

Longer guess: I suspect they are doing some fancy virtualization tricks here to service calls directly like they would a VM but in a VERY lightweight manner similar to containers. This fits with other announcements concerning containers that were also made today.

Again this is all supposition without any actual knowledge.

Depends on a lot of things including bloatware and anti-virus in particular which can slow a machine to an absolute crawl.

In theory windows can be faster than Linux in some cases; but usually isn't because most developers don't actually take advantage of those APIs and just do everything synchronously which is stupid slow on Windows. That said Linux is catching up super quick in terms of those sorts of things.

EDIT: grammar

I have a sneaky suspicion you're right, windows generally assumes any 'shared' code will be in DLLs and is optimized around ensuring they are shared as much as possible in memory. It's likely that if the tests were in a DLL vs. the EXE then windows would just share the CFG page for that DLL read only between all the processes and call it done.

Virtualization does, most virtualization platforms require dedicated lanes for each VM and devices assigned to the VM for dedicated situations.

You should take a look at std::from_chars IIRC it can completely destroy other parsers within the stdlib because it's not intended to take locale into consideration.

https://en.cppreference.com/w/cpp/utility/from_chars

> You can't just blindly compare flops numbers like this. Hitting 13tflops on a GPU implies data has long been loaded into GPU global memory and tons of computations happen on it.

True, saturating a GPU is actually really really hard.

> Not to mention you're limited to 16GB at a time on a Radeon VII and you'd need to either use OpenCL or RoCM which is time consuming.

On a consumer card yes... on professional cards 32GB and up is common. That said most workloads aren't THAT big, and even if they are you can usually stage it in such that the GPU isn't ever really idle.

Vulkan and DX11+ support compute shaders now. MSVC has a custom extension too. There are plenty of compute libraries that exist that will prebuild and do all of this for you. It took me half an hour max to get set up to do this, there are reasonably good tutorials out there.

> Fact is, GPUs are great for a minority of workloads (definitely not most) that are very computationally intense but not memory heavy. As soon as you have lots of reductions, etc. where threads will wait a CPU will also be a much better choice.

Going to disagree here, memory bandwidth on a GPU is insane. HBM2 absolutely blows GDDR5 out of the water on total bandwidth and that blows regular old DDR4 out of the water as well. This is because GPUs would be dead on arrival if they can't actually process data that fast, in fact it's arguable that GPUs are more memory bandwidth constrained than they are anything else. This explains why AMD spent so much of the budget on the Radeon VII on HBM2.

As for reductions, what do you think Anti-aliasing is? There are very well known tile based approaches for this that again, blow a CPU out of the water.

For a GPU the biggest holdback is actually dataset size. Too small and the cost to go over the PCI-E bus in terms of latency will override the savings. If you can do the entire calculation as a series of shaders then write the result back to main memory you can easily out perform any CPU on the market (there are a lot of caveats here however in regards to datatypes, but let it suffice that a professional level card will).

Short answer: it depends.

Long answer: Intel and AMD loooove length prefixes that basically move the base instruction into a new space. Because x86/x86-64 is a variable length ISA they can get away with this. When people like to talk ISA opcode bloat they deliberately include all the prefixes as 'separate opcodes'. Whereas most users would see them as the same opcode, but with modifiers that are not actually 'instructions' per se as the core opcode didn't change. Historically however there are some quirky op codes because of how things were implemented as mentioned elsewhere. So some instructions may have one memnonic but multiple core opcodes due to things like r/m vs reg/reg. This was because traditionally x86 didn't support three operand op-codes, and still doesn't for many general non-vector instructions.

So what I'm somewhat curious about is if this isn't an argument for heterogeneous GPU usage. Schedule this on an iGPU while the main GPU is busy. The main downside, as I alluded to above, would be memory bandwidth unless there is a good on die cache for the iGPU or it has dedicated memory. That said with a multi-gpu setup you might also have another card you could use.

The other thought I have is that it's very difficult to keep the GPU 100% saturated in my experience. If the vertex count is high enough to make the PCI-e transition worth it (and it would seem to be), then you can potentially cycle steal a bit on the main GPU. This will potentially slow down the main render but speed up the overall. This would be particularly true if you can rebind the resource back for use in the main render pipe.

A few thoughts:

* This might be a good candidate for a compute shader, the swizzle abilities of shaders make quite a few of the things they are doing much easier as does the faster memory connections GPUs (usually) have.

* The committee is actually looking at potential ways to handle this http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p110... has been proposed. There is also a lot of discussion about support for GPUs in a standard way, but I haven't seen any proposals myself.

I remember getting to my first Job and they had Pentium4 based machines (the last stepping that supported x64) with exactly 4gb of ram. They were dog slow but it also meant we were able to see and address performance problems early because they were more pronounced. I remember taking one bug from taking an hour to run to less than a second.

It has always amused me that NTFS and NT Kernel are both case sensitive when it comes to filenames. But WIN32 emulates the case insensitive legacy behavior because people won't fix, or can't fix legacy code. That said applications can properly opt into POSIX semantics.

IIRC the newer Unicode collation sensitive comparison functions hadn't been implemented until Vista

Looks like that's the case: https://docs.microsoft.com/en-us/windows/desktop/api/stringa...

This sort of thing is why MS implemented 'PatchGuard' on windows 10 to stop AV vendors from patching OS routines and paths. The system will now bugcheck if the checksums of certain pages change. It also does a few other thing allgedly that MS has deliberately declined to go into detail. But regardless even MS has been fighting back against this garbage.

Honestly the concept here is not new, and the more I think about it the more likely I see levels of storage from fastest to slowest (and capacity in the same vein) ranging from batteries/capacitors to pumped storage systems. Between all of those they should be able to normalize the inputs into the grid I would think.