blu42
blu42 on Hacker News
Intel's SIMD autovectorizer against NV's SIMT was like bringing a sword to a machine-gun war. The fact Intel's own ispc beat that too should have shown them there was an entirely different class of weaponry they should've been developing. Not only didn't they respond adequately, they doubled down on xeon phi.. That's future textbook material right there.
Only now, more than a decade later they realize their mistake and try to correct the juggernaut's course. Such glacial mistakes in this industry can cast death blows to even the largest entities.
That's my understanding as well. Software-wise, I, for one, have not had issues with reading or writing code with branch delay slots -- automatic nops, at worst. I guess it all depends how early in one's development they were introduce to the concept of delay slots.
FWIW, all my laptops are currently arm-based (chromebooks), for the simple reason of price + battery performance.
Unfortunately trade wars are as real as any other kind of war, where 'no holds barred' is the norm.
I'm still amazed how many people fell for the 'concerns of espionage' pretext. I guess most wars in history have started will equally dumb pretexts.
Do you mean at 14nm? I guess once they successfully migrate their actual production line to 10/7nm, whenever that might be..
It's about time societies started processing their own trash. If the economics of processing some kinds trash does not turn out great then maybe we should stop/minimize generating such trash?
The datacentre (AKA 'Neoverse') CA76 variant.
One guess re the second CA76 datapoint would be N1.
Propeller-based airplanes are not that much faster than this train -- current propeller world record stands at 855 km/h. For higher speeds jet/turbofan engines would be the choice, as they are among the few propulsion forms that can operate very efficiently with the atmospheric medium, rather than fully against it (up to certain speeds). So unless you equip that train with jet turbines (impractical for a number of reasons), you will be paying a huge energy price for airplane speeds at ground altitudes (holds true for any kind of ground transportation). As a result those trains are seldom operated at their peak speeds.
It's ok, the oval office might eventually back them on the international markets..
Come to think of it, I believe I might have found a couple of "back doors" in Win 10. Shall I call my EU parliament representative now about trade sanctions against MS, or shall I wait till Monday? Decisions, decisions..
Buffer management is in kernel space, but that's about all that happens in kernel space GPU-wise. Indeed, most interesting things happen in user space.
I have a RK3399-based (same chip as in the PBP) chromebook -- ASUS Chromebook Flip CA101P -- as one of my daily rides. It has no issue playing 1080@60fps & 4K@30 youtubes (I cannot physically output more than 4K@30 to my TV). Its Chrome browser is among the fastest browser experiences I get in my daily routine (which includes linux and windows desktops). On top of it, that chromebook lasts 6-10h of productive usage on a single charge.
Of course, Google's ChromeOS level of polish is a far cry from most 'freely assembled' distros out there, but last time I checked, the ubuntu/debian images for the PBP were getting there in terms of working features and performance.
Doh, my reading balked at the embedded add. Yes, p being a prime actually inverts the statement successfully. My bad.
"Whenever a product m×n is divisible by p, then m or n must be divisible by p."
Actually it's the other way around:
'Whenever m or n are divisible by p, then their product m×n must be divisible by p.'
The opposite is not true, i.e. the statement is not reversible and still true. For instance:
6x4 = 24; 24 is divisible by 8, i.e. 24 mod 8 = 0, yet 6 mod 8 = 6, and 4 mod 8 = 4.
[ed] I've stepped into a cognition discontinuity, move along, nothing to see.
If Intel are stockpiling 10nm parts now (Q2) so they'd have something on the shelves for Q4 then I don't see how their 10nm facilities are in a good shape. Furthermore, when everybody in the industry uses the 'x% yield' metrics, and Intel is using phrases like 'improving at a faster rate than anticipated', etc, to communicate yields, that means their proper yield metrics are far from looking good.
Nope, I'm seeing clasp for the first time -- Christian Schafmeister's talk was extremely nice to listen to!
I did come across some small LISP implementations at the early stages, but by that time I already had the AST builder done. Maybe because I didn't actively search for LISP implementations, as I didn't need a 'proper' LISP per se, more of a DSL for quickly writing ASTs of arbitrary complex computational expressions. Those ASTs were the final goal ; )
Ha! If I only knew about 'Build Your Own Lisp' three months ago!
I needed a simple language as a vehicle for a compiler talk I'm preparing for this summer, so I hacked along an extremely reduced LISP (a 'Non-LISP', as I call it), whose C++ implementation from scratch came out at about 1K -- 1.2K LOC with the AST optimizations I meant to demonstrate for the talk. Self-contained code here -- no libs or (much) STL: https://github.com/blu/tinl
OP, thank you for sharing Tim Morgan's work -- it's a work of love!
Salut! I've finally decided to register for writing, after years of mute reading ; )