2,241 karma · joined May 2, 2017
That's not a given. US did to Japan something similar in the '80s, and they never recovered. Today, ASML is at the forefront of lithography, not Nikon and Canon.
In fact, JIT can perform slightly better once the program reaches "steady state" because it can target the exact processor running and also perform the dynamic profile-guided optimization, which may or may not yield meaningful improvements in real life.
Nick Chapsas did some benchmarking of .NET AOT vs JIT, if you are interested:
You can also compile to bytecode (when building), and then compile that bytecode to the machine code (when running). That way, you can take advantage of the exact processor that is running your program.
This is the approach taken by .NET and Java, and I presume most other runtime environments that use bytecode.
Similarly, LLMs have "hidden layer". We know everything about individual "neurons", but we couldn't connect them together ourselves in a way that training somehow does. The network that is the result of that training is "hidden" from our understanding even though its individual nodes are plain to see.
Since AI can increase in complexity while human brain can't, there may come a day when AI understands the human brain, without the human brain ever being able to understand AI.
Technology Connections channel had a video about that a while back:
The annoying part is that my "untrained" eye is not near-sighted, but my "trained" eye is. I suspect it was different in the childhood (untrained: far-sighted, trained: not far-sighted) and then shifted in the direction of near-sightedness over time.
This may be true in most cases, but not all. It just depends on your access pattern. If all you do are full table scans (possibly feeding to hash-joins), you won't benefit from indexes at all!
The whole point is that indexes do not auto-magically improve performance with no downsides. If they did, we could just index all columns and call it a day!
The other direction, however, is not a given: most DBs will let you create a FK on fields not covered by an index, so deleting or modifying a parent can benefit if you create such index explicitly, because it can check for the existence of children much faster (and avoid potentially locking the entire table). Again, the access pattern governs what indexes are needed: if you never delete/modify parent, you may not need an index on FK (unless you also have some queries which can use it, of course).
No it’s not… if all you do is write to it. In fact, it’s the fastest possible database for such case.
Indexes are pure redundancy - they contain the data already in the base table which must be maintained during writes.
But they can make reads so much faster, if the data access pattern can utilize them. The key is to identify access patterns which justify the price of the index.
I've been writing a lot of T-SQL lately, which doesn't let you declare a parameter or variable as NOT NULL. So it's a good idea to check for NULLs as early as reasonable - usually at the top of the stored procedure (for parameters). Otherwise, a NULL might propagate unexpectedly deep into the call hierarchy and cause less-than-obvious problems.
Fortunately, the data in the table can be declared as NOT NULL, so these kinds of bugs will usually not corrupt the data, but catching them as early as possible makes life easier. However, if there is piece of logic that writes something to the database depending on the value of some parameter, and that parameter is unexpectedly NULL, that might lead to a wrong thing being written, or a necessary thing not being written at all, effectively corrupting the data.
So, defensive programming all the way, baby!
It was objectively better system and that’s why it ultimately prevailed.
Good luck doing that correctly and with good performance, especially in concurrent and multi-client system.
https://stackoverflow.com/questions/20842756/sql-indirect-fo...
That being said, I never saw a gun or even heard of someone having it (in my city of Novi Sad, at least - things may be different elsewhere).
Homicide rates for 2021 (according to macrotrends.net):
Serbia: 1.06 US: 6.81
You can transfer a helluva lot of data after the first byte arrives, but you’ll be waiting for that first byte for a looong time.
It’s unfortunate that the words like “speed” and “fast” are often used without specifying whether that means bandwidth or latency - different scenarios often benefit from one or the other in very disproportionate ways.
The good news is that "smallness of bran buffer" doesn't matter very much if you are trying to implement anything non-trivial. Most useful software is so complex that it's impossible to keep all of it in your head in any case. But we can divide and conquer complexity without holding too much in our limited human heads at any single moment in time.
The real art is how you divide and conquer. Having a bigger "buffer" merely delays (slightly) the point at which you have no other choice but to start doing just that.
There is a difference between somebody selling me poison and somebody selling me “lemonade” that’s actually poison.
Exactly!
That’s why wrapping a “dialog” or “form” or “screen” into a Promise is such a powerful technique. When the user closes the dialog, the promise resolves with a result (e.g. whether the user clicked OK or Cancel), which then you can use for whatever else needs to be done, including invoking another dialog/form/screen!
This makes UI composable, and with async/await “hiding” the promise continuations, the syntax for doing that is essentially the same as when composing ordinary functions.
The difference is much greater than that - one uncached RAM access can take hundreds of CPU cycles.
Yes you could make a CORBA or DCOM object almost indistinguishable from a local object, except for the latency when it was actually remote. And since it looked like a normal object it encountered “chatty” interface which exacerbated the latency cost.
Htmlx seems pretty chatty to me, which I’m sure works OK over the LAN, but what about the “real” internet?
These tests are just normal “unit” tests from the perspective of Visual Studio, which brings one enormous benefit: you can put a breakpoint in T-SQL code and just right-click on the test and choose Debug, and the breakpoint will be hit! That’s possible because Visual Studio debugger can switch from C# to T-SQL seamlessly.
This is a fantastic way to debug in exactly the right test case which exposes the bug or behavior that you want to test.
- Performance
- Consistency
- Security
Basically, you want to construct a public API in the form of stored procedures, functions and views, and then funnel all clients through that API, by granting execute/select permissions only on the artifacts which are part of the public API.
That can be good for performance not just because computation is close to data so you don’t pay the communication cost, but also because it opens optimization opportunities that might be impractical on the client, e.g. by returning several interdependent resultsets at once, or by cleverly using temporary tables or cursors.
It also ensures that a rogue client can’t circumvent the consistency rules implemented by your API. If you care about your data, this is a big one!
And finally, the API may be a natural place for performing authorization in case your security needs cannot be readily met by the database’s built-in security.
—
Perhaps the biggest argument against it is the fact that most SQL-based languages are firmly stuck in the 80s. For the most part, they’re just pain to work with. But enduring that pain might very well be worth the end result.
Quite far, possibly to millions of users.
Case in point: StackOverflow runs on SQL Server.
It may well be that building a brain is easier than understanding it.
The following video has opened my mind. If this is not intelligence, then I don’t know what is…
ChatGPT - Imagine you are a Microsoft SQL Server database server