Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[wierd]

It seems this is even MOAR fun.

The installer dmg files? NOT BOOTABLE.  They do not contain the needed EFI loader.
Apple's directions?
"Use this APPLE ONLY utility to make bootable media! It's SOOOOOOOO EASY! (you just need an already working mac!)"

My solution?

Hunt down an already bootable ISO file (with PIRACY!), use it to set up a VM in virtualbox, enable USB passthrough, cook up a bootable image with my "mac" and go from there.

Because FUCK YOU APPLE. Fuck you in your arrogant asses.

But, it will be another hour at LEAST before that image downloads.  This is getting tiresome.

***
~Several Hours Later~
***

The procedure appears to work. However, I downloaded the wrong osx version. Needs 10.11.3 (El Capitan) not 10.13.3 (High Sierra).  Created media appears to start (yay!), but then says "No, Not supported on this platform!" when started with verbose mode on.

So, MOAR downloading, this time for El Capitan... Then I get to deal with the slow as molasses virtual machine to do the needful... AGAIN.

[bloop_bleep]

Hello all,

My laptop monitor appears to occasionally have horizontal lines on the right side (strictly on the right side, as in it breaks off cleanly at the middle). I found that if I jiggle it and press on it a bit in a certain way it goes back to normal. What's your recommendations for fixing it more permanently?

I have a Lenovo Ideapad 330. Thanks in advance!

[wierd]

The transistor layer is damaged.

If its in warranty send it for service. Otherwise either live with the defect, buy a new laptop, or buy a replacement panel from Alibaba.

-----

I have nearly defeated the macbook repair job.  Hard disk has bad sectors. Zerofilled the drive (after extensive data recovery. Save data first!) to force SMART firmware in the drive to reallocate those from the defect track, do a secure erase to be sure all sectors are reliable to write on after the remapping, then reload with the media made using the virtual ma hine.

Now boots and runs without stalls or hiccups.  Restored user data. Now reinstalling applications.  Informed owner they need to strongly consider getting a new hard drive.

I should have charged money for this.

[methylatedspirit]

Does hyper-threading (or equivalent) affect performance in DF?

[wierd]

Probably not, since DF is single-threaded?

Hyperthreading was an early manifestation of multi-threading. (Literally, still single core, but multiple threads (as long as they were doing different kinds of work) could be executed on the same core at the same time.)

Early OSes treated it like symmetric multi processing, so windows and pals treated it like having a second core.

[BigD145]

Does hyper-threading (or equivalent) affect performance in DF?

Kind of. Forcing DF to move between threads or cores can lead to instability and crashes since DF can only be on one of them at a time. Usually this is seen during world gen. Forcing the OS to keep DF on a single thread or core during world gen can help with those 200+ year world gens. Just make sure you have good cooling on your chip. Part of the reason to move code around is to spread the physical heat and wear and tear.

[Ametsala]

I'm pretty sure that very old, i.e. 2010, hyperthreading strictly divided one physical core to two virtual cores with half the speed, effectively halving the single thread performance. This doesn't happen with slightly less old (2012) hyperthreading, which is smart enough to use the full core when sensible.

This is based on my experience playing DF with an ieee pc with a hyperthreaded processor from 2010(?), and an elitebook with a hyperthreaded processor from 2012. (And an old desktop from ~2005 which had better DF performance than the ieee pc, even though the ieee pc was supposed to have considerably more cycles.)

[bloop_bleep]

Does hyper-threading (or equivalent) affect performance in DF?

Kind of. Forcing DF to move between threads or cores can lead to instability and crashes since DF can only be on one of them at a time.

But isn't it supposed to completely save the thread state when moving it over? Almost any program, single-threaded or multi-threaded, would crash if it experienced some flow disruption due to interrupting the thread or moving the thread somewhere else.

[lethosor]

Does hyper-threading (or equivalent) affect performance in DF?

Kind of. Forcing DF to move between threads or cores can lead to instability and crashes since DF can only be on one of them at a time.

But isn't it supposed to completely save the thread state when moving it over? Almost any program, single-threaded or multi-threaded, would crash if it experienced some flow disruption due to interrupting the thread or moving the thread somewhere else.

Exactly. Any OS that causes programs to crash by moving their execution between cores is buggy. I suspect instances of DF running better when locked to a single core are purely anecdotal. (Incidentally, DF is multithreaded, but each task is delegated to a single thread: one thread each for simulation, graphics, sound, etc. Locking all DF threads to a single core would probably actually hurt performance if one, e.g. the simulation thread, is running at full utilization.)

[Reelya]

I'm pretty sure that very old, i.e. 2010, hyperthreading strictly divided one physical core to two virtual cores with half the speed, effectively halving the single thread performance. This doesn't happen with slightly less old (2012) hyperthreading, which is smart enough to use the full core when sensible.

This is based on my experience playing DF with an ieee pc with a hyperthreaded processor from 2010(?), and an elitebook with a hyperthreaded processor from 2012. (And an old desktop from ~2005 which had better DF performance than the ieee pc, even though the ieee pc was supposed to have considerably more cycles.)

It also depends on how much CPU utilization the program is doing. For example I wrote some code for a class where we had to do threading, this code was data-intensive, and on a 4-core machine (8 hyperthreads), it got linear speedups until I was using the full 8 threads, and it was about 8 times faster than the original single-threaded version. It all depends where the bottlenecks are in your code. Maybe my threads were spending a lot of time waiting for memory, then processing it, then sending it back to RAM, whereas with more threads running, the system could utilize the pipeline in the memory bus much better, meaning the CPU cores weren't idling as much.

[BigD145]

Does hyper-threading (or equivalent) affect performance in DF?

Kind of. Forcing DF to move between threads or cores can lead to instability and crashes since DF can only be on one of them at a time.

But isn't it supposed to completely save the thread state when moving it over? Almost any program, single-threaded or multi-threaded, would crash if it experienced some flow disruption due to interrupting the thread or moving the thread somewhere else.

Exactly. Any OS that causes programs to crash by moving their execution between cores is buggy. I suspect instances of DF running better when locked to a single core are purely anecdotal. (Incidentally, DF is multithreaded, but each task is delegated to a single thread: one thread each for simulation, graphics, sound, etc. Locking all DF threads to a single core would probably actually hurt performance if one, e.g. the simulation thread, is running at full utilization.)

It was a fix for some people, myself included, before any sort of multithreading. It fixed my 40d crashes all the time. It was just world gen that was a source of crashing and almost guaranteed if alt tabbing. Things are a bit more robust now.

[Starver]

Surprised that nobody has mentioned the second core/thread/whatever dealing with the graphics element, if that's still a thing like I understood it to be.

Though it seems (and may still be, even as the Steam version pushes the graphical prestidigitations into overdrive, going from some of our discussions on that bit of the board) that this is a trivial load compared with the heavy data-mangling that goes on in the non-graphical parts of the simulation. (Even without any GPU provision.) So maybe we can treat that as incidental and just fitting into the processor anywhere it isn't otherwise backlogged with the main(er) thread pathing+temperature gradients+liquid sloshing+immigrant biographying+hidden cavingin+etc that is the big bad bottleneck in almost every case...

[lethosor]

Surprised that nobody has mentioned the second core/thread/whatever dealing with the graphics element, if that's still a thing like I understood it to be.

I did
Some print modes (like STANDARD, and TWBT by extension) do use the GPU to speed things up, though.

It was a fix for some people, myself included, before any sort of multithreading. It fixed my 40d crashes all the time. It was just world gen that was a source of crashing and almost guaranteed if alt tabbing. Things are a bit more robust now.

My point still stands - one of the main responsibilities of a modern OS is to keep programs from having to worry about what core(s) they're running on at any given moment (or if they're running at all, since they could be preempted at any point). An OS that causes a single-threaded program like DF to crash if not restricted to one core would likely cause many other single-threaded programs to crash too, and since I haven't seen widespread reports of that, I'm inclined to believe that restricting DF to one core wasn't actually what fixed the issue, at least by itself (although I should be clear that I didn't play 40d, and would be more inclined to believe it if it had fixed my issues). Granted, DF crashes can be pretty nondeterministic, but the most common ones I've seen are due to memory management issues, and a program's memory space is independent of what core it's running on.

[Starver]

I did

So you did. No idea how I skipped that. I don't remember the post at all, must have finger-slipped when reading everything (else!) with such interest.

Carry on...

[methylatedspirit]

Why does DF tend to run better on Intel processors compared to their AMD equivalents? I read this review of the Ryzen 3 3300X and 3100, and it shows that DF generates worlds faster on an i7-7700K (3 years older than the Ryzens). (Here's the link to that section of the review, if you're interested). To me, it's a bit strange, given that the Ryzens tend to be on par with (or in some cases, outperform) the Intel chip being compared (the aforementioned i7-7700K), at least in the review I read.

Why is this the case? Is it just down to single-threaded performance or having less cache, or is it more nuanced than that?