These patents are old news in the UFO/UAP/USO community. It is widely believed to be part of a misinformation campaign. Why would you patent such secret technology like that? On the other hand, it would be awesome if these are real technology we have.
I was an unbeliever, but we got some M1 Mac Mini's and this is the result. They even beat the dedicated workstation many of our people have set up. I get when people say it won't quite match a new ryzen for compute power, but in all of our tests, the M1 beat out all our workstations.
What workloads do you run? I’ve got a 16GiB M1 mbp and a 2019 maxed intel and when compiling Java/sbt projects the intel is significantly quicker, albeit also much loader and power hungry.
Wow, based on the comments here I decided try out the native M1 builds of Azul.
I see a 4.1x speedup in compiling (including tests), excluding dependency resolution:
Azul Native M1 java JDK11:
./sbt "clean;compile;test:compile"
254.86s user
11.84s system
519% cpu
51.375 total
Azul java JDK11:
./sbt "clean;compile;test:compile"
490.04s user
59.48s system
269% cpu
3:23.81 total
> I wouldn't have expected Java of all things to be run under binary translation
Why? The Java community has only just been working on ARM64 support at all over the last few years, and it's still a little limited, and macOS ARM64 support is only out a couple of weeks and only from non-Oracle third-party builders I believe.
You have to install a Java VM compiled for ARM such as the one made by Azul. If you just get the openjdk from the main website it is compiled for Intel and will be much slower.
> I wouldn't have expected Java of all things to be run under binary translation
Depends which version you have installed. It's a taken a while for the native versions to reach the mainstream channels, so unless you've specifically installed an M1 build you probably have an x86 build being run under translation.
Came to comment this. Print debugging makes me so fast at work. Unless you give me an easier and better tool I so no reason to change. Works in every language, exactly how I'd expect, and is exceedingly easy to explain to others.
Print debugging makes me fast too, but there is eventually a breaking point (get it) where print debugging isn't getting me the answers I need and I have to switch to using other options like interactive debugging.
Are you under the impression that investing the time to learn to use a purpose-built debugger will be a net time loss?
I used to print-debug a lot, but since I started working with a stack where I use an IntelliJ derivative - that is to say, where the debugger actually works - and I'm never ever going back. It's better by a huge margin.
Yep. You can blow peoples minds in ANY LANGUAGE by using print debugging sometimes. It's amazing, but true. At least it's been that way for the ~25 years I've been doing it.
You think you're here? Let's put a few print statements in there to confirm your execution path is actually what you think it is, and those values are what you expect them to be.
> You think you're here? Let's put a few print statements in there to confirm your execution path is actually what you think it is, and those values are what you expect them to be.
You could just put a breakpoint there, look at as many values as you want, and not have to re-run it if you think of another.
True, but I don't want to have to exit out of 5 breakpoints each time I run through the scenario. I just want to run it with the print output logging the procession and key variables as a summary of relevant info.
To me that's the key difference. If I know what I'm looking for, prints are great. If I don't know what I'm looking for, breakpoints are a must.
There are a few languages where print debugging isn't as fast, but that always requires a ton of tooling. I found that debugging Java using Eclipse or Intellij was faster than printing, as I could introspect state and change values while the process was running. Similarly, some scripting environments I've used have allowed for robust state and flow analytics.
But in a normal environment ? or using C++ ? It's generally quicker (though much dirtier) to find simple bugs using print statements to track down assumptions ; when you're in the weeds with a complicated problem or need to track down a crash, then yes, bring out the big guns. But for normal development, I don't think it's completely necessary.
Debugging in C++, is a bit of a pain sometimes. GDB tools are good paired with an IDE like VSCode, but due to the abstractions in C++, inspecting variables require verbose code - beyond the convenience of debugging in a higher level language like Python or even Java as you suggested.
Eg: tracking the values of a std::vector isn't obvious, since there is std:begin and std::end iterators in the vector namespace and you have to manually dereference the whole range in the debugger.
I have PTSD to the extent that it affects my employability. I've been fired/laid off plenty. It's the worst part of all my symptoms. If I could maintain employment, I could get therapy. It's tough every time I guess.
I started and ran my own company that really ended up being boutique software (custom websites/servers, custom software, enterprise software repair), but I had a hard time figuring out how to market myself, especially in a more rural area. I ended up making a decent sum of change.
I lucked out and found somewhere to hire me full time eventually so I don't work for myself anymore, but I like have other people do the hard paperwork.
I'd recommend specifically knowing how educated your clients are, knowing how to effectively communicate on their grounds, and knowing how to get to them with advertising. Of course being good at what you do is important, but you'll still go nowhere if you can't do the above. (Also, I find that being a nice software designer pays dividends; nobody wants to hire the jerk)
It's the whole - full core on a GPU aspect, which probably isn't a bad idea for a few reasons, could even offload much of the driver onto it and with that, make platform drivers much more manageable...maybe.
My favorite is to use sibling element selectors and checkboxes to make no JavaScript single page sites. Not the most useful (except maybe for tabs) but a really cool trick non the less. You can really take advantage of the sibling selectors to make no JavaScript modals and menues as well!
Depending on use case, you can even skip the checkbox and use tabindex + :focus/:focus-within as well (I’m doing this for image zoom and footnote-popovers on a project I’m building). And you can use radio buttons for any kind of xor-like state eg tabs.
I do want to add a few notes of caution:
- Edit to add (first because it’s a usability issue for most users): if you use any of these tricks, test on mobile to be sure you have a working escape hatch. For example if you use :focus etc, you very likely want tabindex=“-1” on body to allow the user to exit focus with touch. For checkboxes/radios, you may need some kind of conditionally touchable label to deactivate.
- These kinds of tricks can be awful for screen readers, so do research the appropriate a11y solutions for your usage. And actually test with screen readers to verify you haven’t botched it.
- These kinds of tricks can also wreak havoc with various Readability modes, sometimes totally demoting content arbitrarily. This definitely requires manual testing or automated snapshot testing because most readability modes are intentionally undocumented to prevent cheating.
- A lot of folks recommend details/summary for a variety of interactive behaviors, but don’t fall into this trap. They’re basically a semantic black box for screen readers.
