modern 64-bit cpus (Miscellaneous)
> I can barely keep track of their insane
> naming conventions.
Yes. I really look up everything on the website. I always wonder when people say "i5" or "i7" and expect you to be very impressed (but they didn't tell you the important bit, the generation)
> I swear they intentionally avoid mentioning these details (and VT-X
> and a billion other features, who can even keep track?).
Partially yes to have a really drawn out product-palette.
> > Yes. Note that VT-X is mainly for non-cooperating (full emulation) OSes.
> > Stuff like Linux runs better, because some high bandwidth drivers are
> > replaced by ones that hand it nicely to the hypervisor.
>
> I think they just aren't optimized for tons of mode switches, especially
> not DOS/DJGPP. BTW, obviously VT-X is the new V86 mode (but took forever to
> get propagated to end users).
Yes. Moreover most dos applications use HW directly, so replacing a driver is no good there.
> > Chromebooks are mainly intended to do some surfing (and then mostly "on
> the
> > road"). I avoid them, and the N series in general (though I know some of
> > the later ones are out of order, and not as bad as the early Atom ones).
>
> It's no worse than an Android tablet, just bigger screen and keyboard.
True. I had a Bay Trail one, but the glass cracked unfortunately.
> The only -j4 compiling I ever did was (minimal, for fun) cross-building
> p7zip and building a newer QEMU under Lucid Puppy Linux. "Four" cores
> definitely made a difference.
While some of the FPC parallelism is -j4, it got too complicated, and now there is a separate fpmake tool.
> My brother and I both had AMD laptops back in 2007 or so (both something
> like TK-53 AMD64x2). His was a Toshiba and mine was HP Compaq. Both
> similarly failed/died/overheated.
Yes. I haven't been impressed by the old "Turion" AMD laptops either, but I see Ryzen laptops appearing in shops again (as first AMD options in a decade or so), and hear good things about them.
> But my Dell laptop (Intel) was easily twice as good (esp. battery life).
> Then again, Dell was incredibly biased against AMD for years. So I don't
> (and shouldn't) hold a grudge.
Well, since my last (private) laptop was Sony, and Sony got out of the laptop biz, I'll need to find a new brand
My work laptop is Medion, which is a large German OEM afaik which uses Akoya (or something) branded mobos. Aldi and Mediamarkt/Saturn peddle their stuff.
I bought it mainly because back then they were the only brand that had SSD/HDD combo systems for under Eur 1000.
> > Wait. This summer a Ryzen 4xxx series laptops should come out, and they
> > will be good. My work laptop is up for a change, so I might snap one up
> > myself.
>
> Ever looked at FSF's "Respect Your Freedom" (refurbished?) laptops? I
> forget what that fork of Coreboot is used (Libreboot??). Quite ancient
> (2008-ish?) tech but no ME or PSP or whatever. Not dirt cheap either but
> nothing horrible.
No. I mostly run Windows nowadays.
> > "official" linux branded hardware is maybe not wise. Usually they
> > are targeted at education and research institutions and relatively
> > overpriced.
>
> Software engineers want good stuff, not old refurbished ten-year-old crap.
> SSD, 16 GB RAM, UHD, or whatever. Yes, it's overpriced a bit, but it's not
> for the lowly masses like myself. I just don't majorly want or need
> Windows, even though Win10 has WSL for running Linux 64-bit binaries.
For work I use Delphi and some other IDEs (like Visual Studio and some Netbeans stuff). Using really old stuff hurts. that said, my Ivy Bridge stuff is old, but was decent back then and still sort of works.
> > [Threadripper] is a beast, but also expensive (Eur 4000) a very
> unpractical
> > power requirement (noisy) etc.
>
> Compared to what? I think one person said the Intel equivalent was $10000!
Yeah, and that is overpriced too, the whole segment is. It is mostly for people with per scoket licensed software and a few special purposes.
> > But that is compiling FPC, not compiling WITH FPC.
>
> But ... but ... you compile FPC with FPC! (I did read once that Delphi
> won't build it due to their bugs. Who knows if that's changed.)
Parallelism is a complicated thing with FPC because it has a precompiled header system and finds its own files to compile. (no makefiles with long lists of files to compile). That makes parallel compiling more complicated, and make -j style would cause the various instances to conflict.
While there is some make -j level parallelism, most is on whole directory level. That however only scales so far because there are simply not enough directories independently compilable of eachother beyond 4-5 in parallel.
> I've probably never even rebuilt FPC. I need to rebuild the Go32v2 version
> one of these days, for fun. It really should be buildable in DOS natively
> (famous last words).
It could at some point, though most used Win9x. Later XP.
> Have you seen any Windows
> ARM64 machines? What are your opinions?
Currently irrelevant.
> > That exception does a lot of x87 math. (like sin/cos etc),
> > which seems to be faster in 32-bit, at least with Delphi.
>
> AMD64 went minimal and only supported (like C89 or Oberon) REAL and
> LONGREAL (aka, single and double). Doesn't even FPC "extended" not work on
> AMD64? Meh. So yeah, third-party library needed ... or maybe AVX, dunno.
Windows 64-bit deprecated x87 math. So all math is done using SSE2, which is faster for simple (+-/*) like math, but slower for more complex math (exp(),Sin/cos etc)
> > C++20 has exciting new features like Modules and Coroutines. You know,
> the
> > features that Modula2 had in 1980, and Modules were backported to Turbo
> > Pascal as units in '86 or so
>
> It will be great when modules finally stabilize. I hope they backport it to
> C.
I'm also interested how that works in practice, and how the practice compares to something like TP/FPC/Delphi. Basically most .h/.c files should be easily convertible, if you don't rely in the .h on preprocessor symbols from before the .h's inclusion. Basically that what it is, the bulk of .h(pp)/.c(pp) files that are tightly coupled can then be easier precompiled because the state before the inclusion no longer matters.
That is also one of the fundaments of Pascal/modula2 units/modules.
> The less reliance on brittle (unportable) makefiles and POSIX shell, the
> better. (Doesn't even Win10 have Bash and Curl nowadays??)
No, that is a separate add-on install.
> > Maybe in 2040 they finally realize that = vs == is not smart either.
>
> The switch statement could definitely be fixed.
Yup.
> But they'll probably keep
> assignment in expressions. (Nested functions would be very nice to
> standardize, too. GCC and TCC support it, so do others like D.)
Proper nested functions is a complex topic, specially how nested functions can reach their parents parameters and variables, even when recursing.
Afaik gcc doesn't really support that, only simple nesting.
Complete thread:
- modern 64-bit cpus - Rugxulo, 21.02.2020, 11:40 (Miscellaneous)
- modern 64-bit cpus - marcov, 22.02.2020, 19:31
- modern 64-bit cpus - Rugxulo, 23.02.2020, 02:10
- modern 64-bit cpus - marcov, 23.02.2020, 17:24
- modern 64-bit cpus - Rugxulo, 24.02.2020, 00:11
- modern 64-bit cpus - marcov, 24.02.2020, 21:59
- modern 64-bit cpus - Rugxulo, 26.02.2020, 03:54
- modern 64-bit cpus - marcov, 26.02.2020, 18:11
- modern 64-bit cpus - Rugxulo, 27.02.2020, 12:13
- modern 64-bit cpus - marcov, 27.02.2020, 21:44
- programming language comparison - Rugxulo, 01.03.2020, 11:55
- programming language comparison - marcov, 03.03.2020, 11:46
- programming language comparison - Rugxulo, 03.03.2020, 23:02
- programming language comparison - marcov, 04.03.2020, 11:02
- Minix - Rugxulo, 05.03.2020, 00:12
- programming language comparison - marcov, 04.03.2020, 11:02
- programming language comparison - Rugxulo, 03.03.2020, 23:02
- programming language comparison - marcov, 03.03.2020, 11:46
- programming language comparison - Rugxulo, 01.03.2020, 11:55
- modern 64-bit cpus - marcov, 27.02.2020, 21:44
- nested procedures - Rugxulo, 03.03.2020, 06:05
- nested procedures - marcov, 03.03.2020, 10:16
- nested procedures - Rugxulo, 03.03.2020, 22:19
- nested procedures - marcov, 08.03.2020, 23:08
- ultra-modern x86_64 cpus - Rugxulo, 31.03.2020, 20:29
- ultra-modern x86_64 cpus - marcov, 17.04.2020, 12:02
- ultra-modern x86_64 cpus - Rugxulo, 31.03.2020, 20:29
- nested procedures - marcov, 08.03.2020, 23:08
- nested procedures - Rugxulo, 03.03.2020, 22:19
- nested procedures - marcov, 03.03.2020, 10:16
- modern 64-bit cpus - Rugxulo, 27.02.2020, 12:13
- modern 64-bit cpus - RayeR, 27.02.2020, 05:41
- modern 64-bit cpus - marcov, 26.02.2020, 18:11
- modern 64-bit cpus - Rugxulo, 26.02.2020, 03:54
- modern 64-bit cpus - marcov, 24.02.2020, 21:59
- modern 64-bit cpus - Rugxulo, 24.02.2020, 00:11
- modern 64-bit cpus - marcov, 23.02.2020, 17:24
- modern 64-bit cpus - Rugxulo, 23.02.2020, 02:10
- modern 64-bit cpus - marcov, 22.02.2020, 19:31