If you want to list the information for each of the completed tasks belonging to a certain workunit and you know the workunit ID, then here's an answer.

First of all, if you don't know the workunit ID and you don't know the name of the workunit yet, you could use the Linux program wcgresults to give you workunit results. I'm using it - at least - daily (or even hourly) to show me the latest results.

That's not entirely true: while wcgresults can show you the latest results, it can also record the results into a logfile (even automatically, using your crontab, in a more permanent way) and then you can use another program to show the latest results, for which I'm using the Linux program wcglog. This program can show your latest results - while wcgresults is recording them hourly - by constantly following the output of wcgresults, let's say some sort of 'tail -f', if you wish by using ctrl-Z (to background) and 'fg' to foreground the command again.

The important part is that wcglog can show workunit IDs.

Here is a short sample of a session:
$ wcglog -f -W@l1

App    CpuTime Elapsed Claimed Granted ModTime    Exit Outc SentTime            ReceivedTime        WorkunitId Name
mcm1      0.96    0.96    75.8    76.9 1729962475    0    1 2024-10-23T04:17:47 2024-10-25T08:44:28 619472043 MCM1_0226857_6610_0
^Z

One hour later:

$ fg
mcm1      1.35    1.36    79.1    80.1 1729962967    0    1 2024-10-23T11:10:07 2024-10-25T10:55:58 619679444 MCM1_0226862_8495_0
^Z

In this sample above you'll notice the ID of the workunit that is the outlier, using up 1.35 hours of CpuTime instead of the projected hour (0.96) of processing time. So the workunit ID of the outlier is 619679444.

Now, the quick and easy way is to use the Linux program wcgstats. It can guide you to the workunit if you know (part of) its name; or, if you know its (workunit) ID, it will be even quicker to show the error log for both tasks - and in each error log you will find the name of the executable for the task.

Sample of the Linux session:
$ wcgstats -w -errr= 619679444
workunit 619679444

MCM1_0226862_8495_0  Fedora Linux  Valid  2024-10-23T11:10:07  2024-10-25T10:55:58    1.35/1.36      79.1/80.1
MCM1_0226862_8495_1  Linux         Valid  2024-10-23T11:09:43  2024-10-26T17:16:01    3.09/3.11      81.2/80.1

Details: ---------------------------------------------------------------------------------------------------------------------------------------

MCM1_0226862_8495_0  Fedora Linux  Valid  2024-10-23T11:10:07  2024-10-25T10:55:58    1.35/1.36      79.1/80.1
	Logfile:
	<core_client_version>7.20.2</core_client_version>
	<stderr_txt>
	Commandline =  ../../projects/www.worldcommunitygrid.org/wcgrid_mcm1_map_7.61_i686-pc-linux-gnu -SettingsFile MCM1_0226862_8495.txt -DatabaseFile dataset-curatedOvarian_EarlyLate_v1.0.txt
[snip---8<---snip---8<]
	</stderr_txt>
MCM1_0226862_8495_1  Linux         Valid  2024-10-23T11:09:43  2024-10-26T17:16:01    3.09/3.11      81.2/80.1
	Logfile:
	<core_client_version>7.6.31</core_client_version>
	<stderr_txt>
	Commandline =  ../../projects/www.worldcommunitygrid.org/wcgrid_mcm1_map_7.61_i686-pc-linux-gnu -SettingsFile MCM1_0226862_8495.txt -DatabaseFile dataset-curatedOvarian_EarlyLate_v1.0.txt
	Settings File 
	DateOfDesign = 08/05/2014
	Designer = Krembil-cubes-2023-09-22
	WorkOrderID = 0226862_8495
[snip---8<---snip---8<]
	[08:59:21] Initializing
	[08:59:26] Running
	[08:59:26] EvaluateFitnessOfStartingGeneSignatures 2555
	[12:15:53] Writing final output
	[12:15:53] Closing Output Stream
	[12:15:53] Cleaning up
	Result.out = 1666.000000
	Run complete, CPU time: 11133.991612 
	12:15:53 (8387): called boinc_finish(0)
	
	</stderr_txt>

I klnow it's a long message, so after reading all this, you might be interested in the location of wcgresults, wcglog and wcgstats.
The home of WCGtools: https://sourceforge.net/projects/wcgtools/
Documentation: https://sourceforge.net/p/wcgtools/wiki/Home/ - it is important that you read this! Especially 'Configuration'.
Software - wcgresults, wcglog and wcgstats: https://sourceforge.net/projects/wcgtools/files/

Adri
PS I have described only one particular way to use the programs.
NB The ways in which to use the programs are countless, so there's some learning curve.

Thanks Adri.
I can get the work unit ID from the daily download I keep of each days valid results in a spreadsheet file. Ideally I would batch each day's results and then I could keep some statistics on the various flavors of the executables.
This will be something I will study when I get some time in the future.

Cheers

Use this as cc_config.xml:

<cc_config>
 <options>
  <no_alt_platform>1</no_alt_platform>
 </options>
</cc_config>

Or add the line in the middle if you already have a cc_config.xml file. Restart the client after the change and the issue should be gone. Remember that it's for all projects, so projects, which have only 32-bit applications won't send you any work (for example Einstein's FGRP5 on Windows).

Well, they should run without errors of course, but it's highly unlikely that both are same fast and there's no reason not to exclude the slower one unless you also run projects, which only have 32-bit applications. My Ryzen 5700G completes one MCM WU with the 64-bit application in about 1h20m, with the 32-bit application it needs IIRC about 30 minutes more. So why would I want to allow the 32-bit application and get less work done for the project?

Because without <no_alt_platform> in cc_config.xml your BOINC client reports your system as both to the server: 32-bit and 64-bit. And than the server will send you both and try to determine which is faster.
Once you have run few WUs, it will assign the most WUs to the faster application, but every now and than it will assign one WU to the slower application to verify, that it is still slower.
That way, in case something changes like different workload which completes faster on the other application for whatever reason or if the initial performance estimation was done on some weird WUs (or even on different Hardware in case the User transfers the data folder to new computer), the server can always adapt and send WUs to this application, which is fastest now and not the one which was fastest in the past or the one, which is fastest in theory.

I wonder whether WCG sets the scheduler's prefer_primary_platform flag? If that is set, it shouldn't do that "which is faster" dance [unless there are multiple applications for the primary platform!] :-) -- the rarity with which I see 32-bit tasks suggests that the flag is set!

That would then leave the question as to why the first request to pick up a task for a new work-unit got a 32-bit task, and whether the scheduler just hands off the wingman duties to the first requester it sees that can cope (rather than waiting for another 32-bit-preferred client to ask!) -- the possible reasons for an initial 32-bit send can include someone running a 32-bit client (old build or old hardware?)...

Cheers - Al.

P.S. I have seen the "what app is best" dance on some other platforms that have multiple applications for one platform, but those seemed mostly to be either which floating-point instructions to use (SSE or not?) or choices of GPU application...