Jud

Follow-up. When I put a recursive Fibonacci function in the parallel.for and ran it on various inputs, it worked. When I called a recursive procedure to do Depth First Search (DFS) on a graph, it would not work if it was doing more than one in parallel. But then I made a small procedure to start the recursive calls to the DFS procedure and put that small procedure inside the parallel.for instead of the actual call to the DFS procedure, it works! Just in case someone asks about this.

Well, now it is working.

It is nothing like Fibonacci. It is a depth-first search on a graph. I'm not trying to make the recursion itself recursive - each time through the loop makes an independent call to the recursive procedure. The instances of the procedure don't have anything to do with each other and there is no global data. That is, I need to make parallel calls to the procedure; the recursion itself is not parallel.

The main things I work on are multi-threaded on the 64-bit platform. When I first got Delphi 10.4, I had problems in the IDE: 1. Refactor/rename would not work - it would change only the one at the cursor and none of the others. 2. Find Declaration would not work. 3. Worst of all, after a break, I could not examine variables. Putting the cursor over the variable didn't work. Local variables aren't shown in their window. I had to go back to 10.3. When I got 10.4.1 (about 2 days after release), the problems were gone - until yesterday. Now they are all back. Also, before I think Ctrl-F7 would work to examine a variable, but now it doesn't work. It says "E2003 undeclared identifier". (When debugging, I have {$O-} to make sure it doesn't optimize away any variables.) One thing about my program is that I have a compiler directive to use or not use multi-threading. (I can also set the number of threads from 1 to the number of virtual cores.) I found that if I use the compiler directive to turn off the multi-threading, it doesn't have the problems. If I turn multi-threading back on, the problems are back. I haven't been able to find a solution. Does anyone know how to fix this? ADDED: I went back to an earlier project. and it didn't have the problems. Then I went back to the project with the problems, and it still has them. ALSO: I since it is specific to the project, I deleted the DSK file. Find Declaration works and examining global variables works, but not local variables.

No solution. If I remember correctly, 10.3 didn't have the problem. 10.4 had the problem but then 10.4.1 fixed the problem. But then there were two patches to 10.4.1 that still had the problem. I got 10.4.2 about 3 days ago, and Find Declaration has been working for me. But Refactor/Rename doesn't work (and is worse). Before Refactor/Rename would change the one where you have the cursor, but no others. Now it doesn't even change the one at the cursor.

Thanks, I got it. I read that 10.4.2 retains your old settings. I also read that it requires a complete uninstall, and it defaults to saving your settings. So I did an uninstall first, but it didn't retain my settings.

Where can I download it? I'm a user of 10.4.1 and I had problems downloading the free trial.

I'm getting an integer overflow error when writing more than about 2^30 characters in a tStringList using SaveToFile in 64-bit Delphi 10.4.1. What I think is happening is that it is using two bytes per character and this is putting some number over 2^31 and overflowing an integer. Is this one of the things that they haven't made 64-bit yet? If there are under about 1 billion characters, it works. If there are more, it crashes. When running the EXE file, it just stops running with no message. In the IDE, it takes you to: procedure _IntOver; {$IFDEF PUREPASCAL} begin ErrorAt(Byte(reIntOverflow), ReturnAddress); end; in the system unit. Which brings up another of my pet peeves: 64-bit Delphi has never handled integer overflows properly. A sample program is attached. SampleProgram.txt

So "it isn't a bug - it is a feature"? That 2GB limit comes up in other places too. If it is a design choice, they could choose to design it for modern computers. I remember when Stony Brook Pascal went from 16-bit to 32-bit, there were a lot of places where they forgot to change a 16-bit integer to 32 bits.

But that is a limit in Delphi. It could use 64-bit integers and not have that limit. I think this is an oversight in 64-bid Delphi. Dynamic arrays don't have that tiny 2GB limit.

Is this 2GB limit a limitation in Windows (even 64-bit)??

Thank you. yes, as far as I can tell, the total number of bytes has to be less than 2^31. There are several places where they have not converted to 64-bit integers where they should. Files are bigger now and memories are bigger now.

In Delphi 10.4.1, the following does NOT set Step to 2. Am I missing something? {$DEFINE test2 } ... Step := 0; {$IFDEF test1} Step := 1; {$ELSEIF test2} Step := 2; {$ENDIF}

OK, ELSEIF is NOT an ELSE IFDEF.

Yes, but it isn't as neat or easy as being able to use tStringList.SaveToFile for its intended purpose. I think it is clear that there is a variable in there somewhere that is to hold the number of bytes and it is an integer instead of an int64.

That is a work-around, or using streams with a block size that is small enough to not cause problems.

EditPad Pro can open files bigger than 4GB.

In my development system I have 32GB and an i7. There are 13 computers here, and their memory ranges from 32GB to 512GB. Yes, you get the out of memory error in 32-bit mode, which is why I have to use 64-bit mode. The integer overflow occurs in 64-bit mode when using tStrings.SaveToFile method. The tStringList help page says that tStringList can hold up to 2,147,483,647 strings. But if you have even 1,200,000,000 strings with even one character per sting, you will get the integer overflow error when trying to use the SaveToFile method. And it isn't because of Windows limit on file size, which is much larger.

Not for me. I have never gotten the integer overflow error when compiling in 64-bit mode, and this goes back to the first version with 64-bit platform.

But with the 64-bit platform, why not increase it (use NativeInt). Most computers these days have more than 4GB in them and hard drives 4TB and larger, with large files, are common.

My test case is different, but if I go down to "WriteStringsError.WriteStringsError and click on that, it does take me to the source line after the line that caused the error, so that helps.

Yes, it is, and that makes no difference with an integer overflow in 64-bit mode.

Are you asking about my pet peeve about 64-bit Delphi not handling integer overflows? It has always had this flaw in the 64-bit version. If you have an integer overflow in the EXE, it just stops, with no error message, If you are running it in the IDE, it doesn't take you to the line the error, as it does in the 32-bit version, and, as far as I know, it does with all other runtime errors. An integer overflow in the 64-bit version in the IDE takes you to the obscure place in my message. When I have such an error in a 64-bit program, if I can I switch to 32-bit to see where the error is. But many times that is not possible because the 64-bit version has to be used, usually because of memory. And then it usually takes hours and hours to find the source code with the error.

Here is the problem (a bit of a long message) - I'm writing a threaded program to run on workstations with dual Xeons. Each of the Xeons has eight hyperthreaded cores. (I've read https://www.delphipraxis.net/113427-beginthreadaffinity-setthreadaffinity.html but I don't think it helps me.) Dual-Xeon systems have Non-Uniform Memory Access (NUMA) - each of the Xeons have direct access to their own memory, but they can access memory on the other Xeon - but it takes a long time for a thread running on one Xeon to access memory on the other Xeon. The bottleneck in the program is accessing memory. I have the program set so I can adjust the number of threads it is running. As I test from 1 up to 16 threads, performance improves. TaskManager/performance/Resource meter shows that all 16 threads are running on one Xeon. But if I go to 17 threads or more, it hurts performance (compared to 16 threads on one Xeon). What must be happening is that threads 17 and above are executing on the second Xeon but their memory must be on the first Xeon. That's the problem. I've tried to set the affinity for each thread to a particular CPU and hope it uses that CPU for its memory, but setting the affinity inside a thread isn't working at all (even with only one thread, it runs on all CPUs.) What I have right now is I limit an instance of the program to running 16 threads and I have the affinity set to run on the first Xeon. Then I start a second instance of the program - it checks to see if the first instance is running, and if so, it sets its affinity to run on the second Xeon. Then I merge the results later (which isn't an ideal situation). This is working, with double the performance of running on one Xeon, but it is no different from running on two computers, each with one Xeon. So is there a way to get one instance to use all 32 available CPUs with full performance? (If I could assign each thread and its memory to a particular CPU, that should fix the problem, but I haven't been able to do that.)